CompSci 308
Spring 2024
Advanced Software Design and Implementation

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).
  • 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.
  • “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.
: Packages named api should represent an External API and contain only abstractions (Java interfaces 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 imported 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 Strings 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.