Issue 1: Should the enumerated type's values be named abstractly (Shape1, Shape2, etc.) or concretely (Triangle, Square, etc.)?
Alternative A: Concretely
Advantages: The names reflect what you visually see when you run the application.
Disadvantages: It would not be easy to comprehend if images change (it's not adaptable).
Alternative B: Abstractly
Advantages: The value of the identifiers for the enumerated types are not constrained by what the application actually displays.
Disadvantages: The value of the identifiers for enumerated types does not reflect what is actually displayed on-screen.
Decision: We will name the enumerated type's values abstractly since abstract names are more generic, so it will be easier to change the game's image files without feeling the need to refactor code.
Issue 2: Should java.util.ArrayList or java.util.Stack or a Java Array be used to represent the Deck of Cards?
Alternative A: Using ArrayList
Advantages: ArrayList can resize after an element is removed and an element can be placed at any spot in the ArrayList as long as the index to add at is less than or equal to the size.
Disadvantages: ArrayLists is less efficient than an Array.
Alternative B: Using Stack
Advantages: Stack restricts access to the List of cards to just popping, pushing, and peeking, which are relevant operations on a deck of cards in the problem domain.
Disadvantages: Less efficient than an Array. Does not allow access to the bottom of the deck, which could be useful in the future.
Alternative C: Using Java Array.
Advantages: Uses the least memory and has the fastest access times.
Disadvantages: Management of the Array must be done manually in the Deck class.
Decision: We will use an ArrayList to represent the Deck of Cards. This will allow greater flexibility of the Deck. Even if ArrayList allows access to the cards in ways that are not pertinent in the problem domain, that access can be restricted by the Deck's interface.
Issue 3: Will the game logic lie centrally in a class or will logic be decentralized into each Model class (Deck, Card, Table, etc.)?
Alternative A: Centralized logic
Advantages: A single class will have the responsibility of running the application. It also simplifies the solution model by abstracting the game rules into one class.
Disadvantages: That class will be a large class since it implements all the game's rules.
Alternative B: Decentralized logic
Advantages: We will only need a small delegator class and it will only have to delegate to each of it's composing classes.
Disadvantages: Retrieving the correct game logic from each class will become a daunting task.
Decision: We will make decentralize all interactions between the User Interface and the rest of the classes. It class will be in charge of some game logic. As an example the isASet(), getDisplayed(), and setIsAvailable() methods from the Table class are not to be send to the GameController class. The whole point of object-oriented programming is decentralization.
Issue 4: Should we have a ScriptedPlayer to run automated tests, even though we already have a ConsolePlayer for manual testing?
Alternative A: Implementing ScriptedPlayer
Advantages: It will speed up regression testing and allow automation of many use case tests.
Disadvantages: ScriptedPlayer carries out most of the same functionality as the ConsolePlayer, so it may be redundant.
Alternative B: Not implementing ScriptedPlayer
Advantages: Fewer classes to make.
Disadvantages: Limits the scope of our automated testing.
Decision: We will implement the functionality of ScriptedPlayer by invoking the class with a special argument such as the script's filename. The creation of a separate class would be beneficial.
Issue 5: Should we use use default collection class or self-made collection class to handle High Scores?
Alternative A: Default Collection class
Advantages: Default Collection class does not require much time and have reduced error due to proving of many prior developers.
Disadvantages: We can not add method that we may need while using a default collection class.
Alternative B: Self-made Collection class
Advantages: We can add necessary methods as we need while writing the code for our application.
Disadvantages: Time consuming and the classes that are self-made are more error prone.
Decision: We are going to use the default collection class. Since CPE 309 is a time intensive class our team do not have sufficient time to write our own collection class and fix errors.