CompSci 308 : Spring 2024

OOGASalad: Design Specifications

You will be accountable for ensuring that your code's design meets these specifications that you have practiced in previous projects. The table below follows the format in the Design Requirements Glossary.

Design is more important than functionality for your final grade and you should not expect to meet all the design requirements by simply getting it “working” right before the deadline.

ID	Name	Priority	Description
`DESIGN-01`	Multiple Classes	Complete	Code should be divided into several classes that each have a useful purpose (i.e., non-get/set methods). Avoid these code smells: large class and data clumps.
`DESIGN-02`	Named Constants	Complete	Named constants, including numbers, strings, and Enums, for values used multiple times or in program logic. This includes being declared as final variables with an intention revealing name.
`DESIGN-03`	Don’t Repeat Yourself (DRY)	Complete	The same lines of code should not appear in multiple different places in the same project (i.e., they should not be duplicated). Instead, the code should be refactored so that the duplicated logic is written only once and called from many places.
`DESIGN-04`	Tightly Scoped Methods	Complete	Each method should be small and single-purpose. Long methods should be decomposed into smaller pieces of functionality. Long methods are a code smell.
`DESIGN-05`	Code Formatting	Complete	Code should follow course formatting conventions, including things that cannot be automatically checked, especially the Java naming conventions.
`DESIGN-06`	Interact Through Methods	Complete	Classes should avoid inappropriate intimacy by collaborating via method calls. A class should not directly access the instance variables of another class. Do not use public instance variables or global variables.
`DESIGN-07`	Comments	Complete	Follow Javadoc conventions for commenting on public classes, interfaces, methods, and packages. In-line comments should be used judiciously; self-explanatory code is preferred. See Internal Documentation.
`DESIGN-08`	Incremental Delivery	Complete	Your team's project GIT repository should show many, purposeful commits from all team members rather than just one or two large “kitchen sink” commits and marathon merging or redesign sessions. Commit messages should include the requirement number as described in the requirements glossary, starting with either `[OOGA-NN]` for new features and `[DESIGN-NN]` for refactorings. NOTE: Each person must push at least four commits each week to the `main` branch that show just the results of refactoring existing code to improve its design.
`DESIGN-09`	Model View Separation	Complete	GUIs should be separate from the model; this requires clear articulation about what information (including errors) needs to be communicated between each part. NOTE: You may optionally include a Controller from Model-View-Controller if your team has complex logic for handling user inputs that results in code duplication or tight coupling between View components. The View should be a collection of classes in package called `oogasalad.view` and its sub-packages. View classes in these packages use OpenJFX to display to the user and interact with the Model. The Model should be a collection of classes in a package called `oogasalad.model` and its sub-packages. View classes in the these packages should not import *any* classes from `javafx.*`; being agnostic to how the information is presented to user.
`DESIGN-10`	Encapsulation	Complete	Key implementation details *must* be hidden such that they can be changed *without impacting any other classes*.
`DESIGN-11`	Make and Use Abstractions	Complete	Create abstractions that capture commonality (superclasses or interfaces) and encourage variability (subclasses or implementors). Build your classes to depend on the abstractions (superclasses and interfaces) rather than implementations (concrete subclasses). EXAMPLES: Use the most abstract collection possible (i.e., `List` instead of `ArrayList` and `Map` instead of `HashMap`). Do not downcast to specific subclasses or use `instanceof` checks (except in `equals()` methods).
`DESIGN-12`	Externalize Configuration	Complete	Move hardcoded values into configuration files, stored in `src/main/resources`, rather than compiled into your program. EXAMPLES: “magic” values stored as `static final` constants any text displayed in the user interface, by using resource property files (the `String.format()` method allows you to make any complex string a single value) any styles (colors, font, borders, etc.) used to customize the user interface, by using CSS files NOTE: Each program should support at least three Theme options (such as Dark or Light modes, Duke or UNC colors, larger fonts for presentation mode, etc.) and at least three languages (Pig Latin is a popular option or you can use Google Translate if no one on your team can do it).
`DESIGN-13`	Programs Should Not Crash	Complete	Build robustness into your program so that it does not crash or hang. Handle errors and provide a reasonable response to exceptional cases so that the user can continue to run the program.
`DESIGN-14`	No Dead Code	Complete	Your project should not include unused variables, methods, or classes. Do not comment out blocks of code to save them for later; instead, use your GIT history to find old code.
`DESIGN-15`	Handle Errors Using Exception Flows	Complete	Communicate errors in a thoughtful, intentional, manner rather than returning `null` or other error prone values. Consider using custom Exceptions or Java's `Optional`.
`DESIGN-16`	Explicit Immutability	Complete	For classes and values that should not change after they are instantiated, explicitly restrict them from changing using language features. Consider using Enumerated types or Records.
`DESIGN-17`	Model API	Complete	Provide well-defined Application Programming Interfaces (API)s for logical parts of your project. The View should only interact with APIs. Each class and method should have complete Javadoc comments. NOTE: Packages named `api` should represent an External API and contain *only* abstractions (Java `interface`s or `abstract` classes), purely immutable classes, or Exceptions to be used by other packages. The internal code, consisting primarily of concrete subclasses that are not `import`ed or known about directly by other packages, should be in other sub-packages.
`DESIGN-18`	Automated Testing	Complete	Your program must be tested using JUnit (with assertions both for typical situations and possible thrown Exceptions) to verify it works as intended. These tests should be a mix of: Model Tests: tests that test one small unit of functionality End-to-End Tests: tests that simulate the user interacting with user interface (using TestFX) Your testing goals are to: write JUnit Tests for each concrete class with at least two well-named tests for each non-trivial `public` method (more than two for complex methods) write at 10 negative scenario JUnit Tests where the expected behavior is to throw an Exception achieve at least 85% line test coverage overall NOTE: Each person must push at least four commits each week to the `main` branch that creates or updates tests.
`DESIGN-19`	Reflection for Instantiation from Strings	Complete	Use reflection whenever you need to create objects or call methods from `String`s rather than hardcoding conditionals or a mapping between the `String` literal and your object.
`DESIGN-20`	Apply Design Patterns	Complete	Define and describe your system design using Design Patterns. Your classes should follow the naming conventions of the design pattern you are applying (i.e., a factory class from the Factory pattern should be named with the suffix `Factory`). Document your Design Patterns where appropriate, such as Javadoc comments and the project `DESIGN` document.