Implementation of the Codurance command line social exercise.
This is a maven project that requires java 8. To build run 'mvn clean package'.
From command line, in project root, run 'java -cp target/cmdline-social-1.0-SNAPSHOT.jar za.co.codurance.social.ui.console.App'
- 'exit' can be entered to exit app. This also means that we cannot have a user handle of 'exit'
I sketched out some simple CRC cards and diagram to get a basic view of the problem. High level project structure uses Actions, Domain Services, and Repositories similar to Interaction Driven Design model. Following aims/purpose was:
- to explicitly introduce concept of use case messages to drive the interaction at the high level i.e. wanted an explicit message request to reveal intention of boundary calls into the actions.
- wanted to try having the clear boundaries between Actions, Domain Services, and Repositories.
- even though not requested wanted to keep in mind how design would cater for adding anothe kind of UI onto i.e. web instead of console. This impacts the boundaries of the ui controllers and actions.
- avoid field access and rather use private getters (wanted to see if it affected readability or coding time)
- wanted to drive bottom-up TDD as haven't practiced TDD in anger with current projects.
- You could probably come up with simpler and less code if you relax some of these assumptions.
- I also wanted the commit history to be explicit and viewable but unfortunately the way I started the project was standalone using local history in IntelliJ.
Design notes:
- Initially I was leaning towards Command objects to handle the actual execution of the use cases but ended up with handlers that process the input and act as controllers. This is probably due to my starting in a bottom-up approach to the functionality as opposed to a top-down.
- Not too happy with the outcome of the handlers in terms of the disconnect between parsing input and controlling interaction with user. I say this because it makes it more difficult to see the type of inputs that can be executed and also introduces complexity in ordering of handlers e.g. Exhibits Positional Connascence where the order of execution of the exit handler is important so that it is not interpreted as a user handle.
- Some of the code was put in place so that it is consistent and match other similar classes e.g. private getters, small intention revealing methods, keep code in methods at same level of abstraction where in certain cases it could have been relaxed (i.e. a method behaviour was simple enough to call a repo directly but rather follow similar impl so that there is a general consistency, although even for me it is a little jarring at times and I'd relax this to fit in with others coding styles).
- I would probably redo the UI/console code and drive it top-down earlier on in the process until it hits the action classes, then potentially drive it bottom up from there.