Skip to content

hmqyu/cat-avatar-maker

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

30 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

My Personal Project - Cat Avatar Maker

Introduction

My proposed application is a play on the typical avatar makers found online: instead of human headshots, there are cats! These are fully customizable - in fact, you can customize:

  • Colours (eyes, nose, markings, etc.)
  • Adding accessories (hats, bags, and even wings) and backgrounds
  • Changing the direction it's facing

This app is aimed at the general public, with a specific emphasis on those who like cats and avatar makers in general. I have a lot of friends in the artist community that use avatar makers, so I know there's a population out there that would appreciate this app. I personally love creating art and programming, so I also thought this would be a good way to demonstrate both of my skills (while also showing my love for cats!).

User Stories

  • As a user, I want to be able to name my cat.
  • As a user, I want to be able to change the body, colours, and patterns of my cat pixel.
  • As a user, I want to be able to add accessories or a background to my cat pixel.
  • As a user, I want to be able to make the cat pixel face left or right.
  • As a user, I want to be able to save a cat I've made to a cat collection.
  • As a user, I want to be able to reload a cat I've made from a cat collection.

Instructions for Grader

  • To generate the first event (a cat), run the CatMaker class located in the "ui" package. Click the "New" button from the initial menu window.
  • Second events are generated by modifying the cat: you can add patterns, accessories, and backgrounds to the cat. Unrelated, you can change the cat's base, skin, and eye colour as well. These are all done by clicking the respective buttons after hitting "New".
  • My entire project is one huge visual component made up of smaller visual components. Everything that doesn't look like it's system-made is all digitally drawn by me.
    (catch me on sixverba @ twitter/instagram LOL)
  • You can save a cat you've made by clicking the "New" button from the initial menu window, and then selecting the "Save Cat" button from the next window. You will be prompted to enter a name for your cat so you can distinguish later saved cats from it.
  • You can reload a saved cat by selecting the "Load" button from the initial menu window, and clicking on the button of the cat's name you'd like to reload.

(Currently, there is one Easter egg implemented. Hint: blue eye.)
(There's also one "Easter egg" in the files, but is not present in the actual application.)

Phase 4: Task 2

I have decided to go with the "Test and Design a Class That is Robust" option.

The method that throws an exception is called parseCat. It is located in the SaveDataReader class, starting at line 77 (the exception is thrown at line 90). I did this because I thought it would be a good idea to check if the save data was corrupt or not (eg. something was not written correctly, the user purposely modified the text file where the data is stored, etc.). It is very useful when debugging the code, as it indicates there's an issue with the save data that is being written rather than something else (eg. another array that deals with displaying accessories in the GUI).

This method is tested in the SaveDataReaderTest class. All tests in that class either test the case where the exception is not expected, or where the exception is expected. The test where the exception is expected is called testSaveDataException and begins on line 99.

Phase 4: Task 3

1) One of the biggest issues I noticed was that there was a lot of repeated code in my GUI/UI package. Most of this repeated code occurred when creating new buttons, as practically every button used (ie. all but the buttons used for cat names in the LoadPanel class) had a specific background image and drop shadow. With each class having anywhere from 1 to 11 of similarly-created buttons, my program had incredibly high coupling.

To combat this, I decided to make a new class called ButtonVisualsMaker. Using its constructor, I could retrieve a button's background image through a String parameter. Then I would be able to create a button with its respective image and drop shadow (the latter using the addDropShadow method to do so), for any button used in the GUI (excluding the ones used for the cat names in the LoadPanel class). This dramatically reduced same-code repetition between classes, leading to looser coupling. As well, this increased cohesion because the panel classes, whose main jobs were to create interactive scenes, no longer had to process the visuals of their buttons directly.

2) Doing this made me realize that there was also heavy repetition present in the MakerAction class and subclasses. Each class was essentially a clone of itself with very minor changes specific to the action that needs to be done. Namely, several classes employed the same for-loop structure to create and place buttons on a StackPane at certain, static positions. As well, all the constructors for those classes were virtually the same (all but one called the super constructor and a method called loadColourButtons).

Here, I chose to turn the MakerAction class into an abstract class, and turn the loadColourButtons method into an abstract method in the MakerAction class. This removed the variation in the subclass constructors, as now they all relied on the superclass' constructor. Since MakerAction was never directly instantiated, making this change did not affect the rest of the GUI. I aso created a method called setColourButtonPosition, which would handle setting each button's position at their intended location. Additionally, a refreshCatModel method was implemented to handle refreshing the cat model after changing something about it, which was used in each MakerAction subclass' buttonAction. I also ended up refactoring the EyesAction class to reduce internal code repetition as well.

Again, this reduced same-code repetition between classes, also leading to looser coupling (but maybe not to the same extent as before). Arguably, cohesion increased as well: MakerAction and its subclasses adhere better to the Single Responsibility Principle. This is because MakerAction solely handles creating the button visuals on the action panels, and MakerAction's subclasses now only handle changing their respective part of a cat through the buttons.

About

an avatar maker for entirely-customizable cats. complete with a GUI built in JavaFX.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages