Re:A Database Model for Simple Board Games
by lewisl9029 on Friday March 11, 2016 @03:06PM
(#11269126)
I personally prefer a more data-oriented approach to modeling, as opposed to modeling in terms of objects and relations. One of my favorite videos from Clojure Conj last year talks about the approach in more detail and contrasts it with traditional OO modeling in the context of a board game:
In summary, modeling the board game with data (state) and pure functions (state transitions) had significant benefits over the alternative OO style model in terms of the overall simplicity of the model. The OO modeling approach resulted in a model that consisted of 22 classes, 11 interfaces, 1 enum, and 271 lines of boilerplate code just to implement the classes and relationships alone, with no game logic whatsoever. On the other hand, the data-oriented approach produced an entire working implementation of the game logic in 144 lines using 31 functions (small and highly composable functions, longest of which was 7 lines).
My takeaway was that modeling in the traditional OO style can be a helpful process in getting a good feel for your problem domain at a high level, but trying to immediately translate the resulting relationship model into code is not necessarily a good idea, because the classical OO relationship model is inherently highly complected, and will bring that complexity straight into your codebase if you try to translate it word-for-word. Taking the insights from your relational model and using it as a guide to help model your problem domain as data and functions usually results in a much simpler codebase, and in turn, a much more robust and predictable application.
https://youtu.be/Tb823aqgX_0
In summary, modeling the board game with data (state) and pure functions (state transitions) had significant benefits over the alternative OO style model in terms of the overall simplicity of the model. The OO modeling approach resulted in a model that consisted of 22 classes, 11 interfaces, 1 enum, and 271 lines of boilerplate code just to implement the classes and relationships alone, with no game logic whatsoever. On the other hand, the data-oriented approach produced an entire working implementation of the game logic in 144 lines using 31 functions (small and highly composable functions, longest of which was 7 lines).
My takeaway was that modeling in the traditional OO style can be a helpful process in getting a good feel for your problem domain at a high level, but trying to immediately translate the resulting relationship model into code is not necessarily a good idea, because the classical OO relationship model is inherently highly complected, and will bring that complexity straight into your codebase if you try to translate it word-for-word. Taking the insights from your relational model and using it as a guide to help model your problem domain as data and functions usually results in a much simpler codebase, and in turn, a much more robust and predictable application.