Above is a dependency graph generated by the ns-dep-graph lein plugin for my Clojure Tic Tac Toe game. The colors are to show what constituted a dependency and has the wonderful legend that describes what each of the hues mean.
Based on this graph, I can’t say whether it fully follows the Dependency Inversion Principle (DIP) or not. It is sort of a mix. There are points where it does, and points where it does not. I’ll go through them.
Points where DIP holds:
-
The scoring repository/interface/each storing type chain. The implementations of how to write/read from the particular file is implemented in the scoring_
files but the core methods for each are laid out in the scoring_repository. The repository is depended on by the score recording file where the more business and integration logic take effect. There is also some methods that overlap with json and edn, so they were placed into their own file and those two modules depend on that. -
The game menu file is depended on by each of the options. The game runner only depends on the options so that the implementation of the defmethods apply. The options for the menu are implemented by the option files.
-
The game functions, the higher level abstraction of how the game works, is depended on by the two files that use it, namely the ai_player and the play_game file.
-
Game messages being saved in the localization file rather than directly into the console input ouput.
Points where DIP falls apart a bit:
-
How the game runner class depends on the implementation of all the scoring classes and that a few of the methods are not used by it. This is because the methods need to be required somewhere and that was the place to do it, but it makes the graph look like an octopus.
-
Display previous scores depends on the the implementation of both the score recording and console input output class, and the latter implicitly requires a certain format for the former.
-
The keywords for localization are known in the game menu file and console i/o knows about the details of localization asides from just using translate.
-
The structure of play game and the option for it. They rely on a variety of different files and their particular implementation. It looks a little messy.
So, it is pretty much a mix. I’d like to think it is a pretty fair mix, but I am biased towards my own benefit. There are probably ways to invert it more so that there are more abstractions that are relied on, but I can’t think of any.