Cell Society : Generalize and Robustness Implementation

Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another. — Allen Holub

This part introduces new features intended to

• improve how your project handles erroneous situations to be more robust and better inform users of data issues
• expand your GUI to give users more access to controlling their simulation experience
• reduce hard coded values in your GUI to make it easier to customize to user's needs

While you are welcome to use GIT tags anytime during your project to annotate an important commit, you must tag the commit your team feels is the finished version for this deliverable as General.

Advice

• Focus on Design: add new features deliberately, with the goal of improving the project's overall design and following the team's goals and priorities
• Design is Vital: spend as much time during this deliverable refactoring your code as you do on implementing new features, strive to first change the code's design to make it easier to implement the next feature
• Robustness: look for places in the Model to throw Exceptions, rather than returning null, that can be caught in other packages (e.g., the View)
• Testing: test explicitly for thrown Exceptions thrown from the Model
• Encapsulation. hide the grid data structure's implementation completely!
• Use Polymorphism: there should not be any need for conditionals that check for concrete classes (except for purposes of calling new (until we replace that with Reflection))
• Active Classes: make methods that use the class's instance variables instead of giving them away — rein in the get/set methods
• Resource files: set these up as early as possible and strive to remove hardcoded assumptions as you go (so you get used to doing it, find more opportunities to use them, and do not accumulate a large future task)

Generalization and Robustness Requirements

Build on your Basic version to add these variations to each part in a thoughtful manner that clearly shows the intentions of your design goals and avoids duplicate code structures. The best strategy is to make your core classes closed to modification while open to extension by depending mostly on abstractions that hide the implementation details. Simply adding extra functionality not related to an abstraction or adding poor code that exposes implementation details, adds special case conditionals, hardcodes values, or otherwise diminishes the rest of your design efforts will not be rewarded.

Refactor and implement as much variety as you can to clearly demonstrate your design supports further such extensions. If you are not able to implement a variation, you must still be able to justify that your overall design handles adding it in an intentionally well designed manner in your DESIGN document.

The full list of new functional requirements is given here. The design requirements remain the same.

Property Values

Data files saved and loaded by users should be considered External, optional data typically available to be updated by users of the program, and contained in data folder at the project's top level.

The View must use configuration file(s) for the details of its components instead of hardcoded values within your Java code, specifically: 

• Resource Property files: for any text displayed in the user interface (using the String.format() method to make any complex string a single value)
• CSS files: for any styles (colors, font, borders, etc.) used to customize the user interface

These files should be viewed as Internal, essential to the program's proper functioning, and contained in the project's src/main/resources folder.

In addition to representing all text displayed to the user (including error messages), consider using separate Property files to configure as many magic values as possible within your code so they are easily changeable without re-compiling your code. For example, we will discuss Java's Reflection capability to create instances and call methods using strings to expand what you think of as "magic" values and increase your code's flexibility.

Strive to move hardcoded assumptions into configuration resource files -- it should be possible to have separate runs look very different by changing only property files, rather than recompiling the program!

GIT

Your team's project GIT repository must continue to show many, purposeful, commits from all team members. Your commit messages must reference the Issue and Functional or Design Requirement ID represented by your code changes following this format.

Everyone must push at least five commits that show the results of refactoring existing code to improve its design, with a commit message that references the Design Requirement ID represented by the code change.

Testing

Again, you must continue to show improvement in the habit of creating easily repeatable ways to validate your confidence in your code, especially regarding robustly handling erroneous situations. This article provides guidance about “negative” testing, i.e., how to think about what kinds of input errors might occur when coming up with tests.

We will check that each person regularly commits tests and test data files rather than waiting to do it until the end.