Bottom Up vs Top Down Design in Clojure - Mark Bastian

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: [this video] 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 usuall

This is exactly my impression after taking a quick glance through these articles as well. If anyone is curious and would like to see a practical demonstration of this data-oriented approach of modelling problems, I highly recommend this talk from Mark Bastian in Clojure/conj 2015: [this video] In it, he contrasts the data-oriented modelling approach with a traditional OOP approach for implementing a board game, and was able to come up with a complete implementation of the game with the former approach that was shorter than even the structural boilerplate for the OOP version. Another related talk that I loved was Chris Granger's 2013 talk on Light Table: [link] Where he walks through his process of building a game in ClojureScript using an Entity-Component-System architecture, which is very well suited to this data oriented modeling approach.

Thanks for the link. That made my day. =) Here's a more realistic comparison between classic Java OOP design vs the more data-oriented approach to design encouraged in functional languages like Clojure for a simple board game: [this video] TL;DW: The classic OOP design of the board game ended up with 22 classes, 11 interfaces, 1 enum in total, with 271 lines of pure skeleton code with no implementation of any game logic whatsoever. The class diagram can be seen here for a better sense of the complexity involved: [this video] The data-oriented design had 31 functions, longest of which is 7 lines, with a grand total of 144 lines of code that implements the entirety of the game logic.