Architecture

Live UML

We explain things in "general" here, the implementation details can be seen in the code itself.

There are 3 layers:

1. Presentation - everything you see on the screen. For example Swing's windows, buttons, text fields and code that reacts to clicks and keystrokes.
2. Domain - This is the core of the app. It is responsible for tracking what was typed, and calculating results like WPM and accuracy. The layer has no knowledge that Swing even exists.
3. Service - These are service classes each have their own purpose and should be looked up in test package or directly in code. Since there are no docs yet.

The main intention for splitting code layered like this is because the Domain layer can be tested completely on it's own. It will be much easier for everyone to add tests.

Each screen (say, the typing test for the sake of example) is split into two objects:

1. A View - It only knows how to display things it's told, like "put this text in this label". It never decides what to show.
2. A Presenter - It figures out what the view should display, and tells it.

This separation is done because one can test a Presenter by giving it a fake view (just a stab that remembers what it was told) without ever opening a real window.

There is only one Window instance, and different views are swapped in this window to show different things. The AppCoordinator decides which view to show in the window instance. So, if you are willing to add new view you might want to look at that class.

I use googles' dependency injection tool called Guice and it is mainly used to connect each Presenter to its View, or connect Presenters to the Domain classes they need, etc.