Cell Society : Change Implementation

First make the change easy (warning: this might be hard), then make the easy change. — Kent Beck

This part is intended to emphasize the project Design Specification by introducing new features that challenge assumptions you may have made to expand:

• Model: handle different kinds of environment requirements
• Configuration: handle "styling" simulations
• View: handle multiple Views with different Cell shapes

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 Change.

Advice

This is your last chance to demonstrate that you have learned to write thoughtful code that clearly shows your design intentions in this project, following:

• Current and New Project Design Requirements
• SOLID Design Principles to properly support Encapsulation and Polymorphism
• Design Patterns to help you describe your design and guide your refactoring efforts

This is your last chance to demonstrate you are developing software using a professional process by

• merging Clean Code to the main branch (i.e., code that has gone through multiple drafts)
• writing descriptive GIT commit descriptions that reference a specific issue and a clear purpose (new feature, bugfix, refactoring, testing, etc.)
• updating Gitlab Issues as you start and finish your features
• pulling code regularly to stay up-to-date with each other's work
• testing your code regularly, including the View
• using internal configuration and resource files to remove hardcoded assumptions in your code

Everyone should help get the team's priorities done — even if it means sacrificing your own part's extra features.

Changes

Build on your General version to add these variations 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 APIs closed to modification while open to extension by depending mostly on abstractions that hide the implementation details. Simply adding extra functionality by substantially changing your APIs, 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. There are also additional design requirements.

API Mindset

Develop intentional APIs, the public classes and their public methods, for the backend (Simulation and Configuration packages) as a service to the View client and support for future changes. While an external API for the View is not required, you can certainly create an "internal" API that goes beyond basic implement ion and looks for places to create abstractions to support "internal" extension points for flexibility.

All public API classes and methods should have complete Javadoc comments, especially interfaces and abstract classes to show their intended use. You should be able to justify every public method's value to the API's Design Goals and Contracts.

Describe the design goal of each package's API in a file named package-info.java.

Logging

All programming languages have some kind of logging library, that make it just as easy, because logging is preferable to printing, letting you:

• Control what’s emitted, easily turning it on or off to get more or less information
• Define what types of information you want to include in your logs
• Configure how it looks when it’s emitted
• Most importantly, set the destination for your logs

It is fine for debugging messages to continue to go to the console (standard out), but ERROR and FATAL level messages must be saved to a file in the log folder.

Use Log4j2 to output different levels of information rather than println() statements, including any time an Exception is thrown.

View Testing

Continue to test your View using TestFX to simulate common user "actions" and common JUnit assertions to verify the UI responds appropriately (including changing languages, styles, and appropriate response to thrown Exceptions). Still look for ways to test your View classes or otherwise group your tests around similar actions. These tests take longer to run, so run them individually as much as possible.

Aim for about 50% Line test coverage of the class it is testing.

To demonstrate that you are following good testing process, aim to include new or updated tests with each Merge Request to main that adds new features or fixes bugs.

README

In addition to organizing your code according to the Submission Guidelines and documenting your code, complete your README file — especially documenting your assumptions about the functional requirements and attributions for any images or resources you used.

The DESIGN document will be completed as part of the after project Analysis.

As a reminder, describe each potential error checked for to prevent your program from crashing and how they are handled.