The past few times my mentor has looked at my code one of the things he has told me is that I need to decouple my UI from the rest of the game. At the moment my game logic is dependent upon the way that the user interacts with the game, waiting for a person to type in their input, be it square selection, marker type, opponent type, board size, or whether or not they want to play again. This type of interface does not work for the web, however. Instead, the web interface is going to be checking the values selected for cookies and feeding those into the game logic.

Until mocking out a fake web-interfaced tic tac toe game, I really had no idea what sort of problems I would encounter. I didn’t understand why my current architecture was not very modular, much less what good architecture is supposed to look like. Another apprentice, Angeleah, pointed me to a blog post she wrote when she was having a similar issue, which led me to three pages of notes from watching Uncle Bob talk about Architecture, Use Cases, and High Level Design (warning: paywall).

The crux of what I learned is that I should focus on building my code around particular use cases that are independent from the interface. It should not matter whether the application is used with a GUI, a web interface, or a console. Nor should it matter the type of database with which the application is interacting. Well-architected code will not depend on these decisions. Instead, one should delay these choices and build code that is delivery-agnostic. As Uncle Bob says, good architecture maximizes the number of decisions not made.