#begin

Heya there again and welcome back for another blog about A Philosophy of Software Design. Today we will be looking into chapter 8. Let’s dive straight in.

Pull complexity Downwards

Chapter 8 is about pulling complexity downwards. This chapter provides some mote depth, no pun intended to the concept of deep modules. It boils down to the idea that it’s more important for a module to have a simple interface than a simple implementation. This also relates back to information hiding I think, and proper encapsulation. John says that sometimes you can simplify an interface by having some kind of config file you can add to a system. This config file can then enclose some of the more complex settings and you can leave it up to some system configuration to deal with that complexity, instead of a programmer. This is brilliant, isn’t it? He’s totally right! This is also mentioned in The Pragmatic Programmer if I’m correct. Use config files to reduce complexity and promote reusability. Just don’t go overboard with it since we don’t want to flood other people with our problems of course. It will reduce complexity in the short term, but might slow you down in the long term so keep an eye out for overdoing it.

So for example, in a Unity context, don’t put all the complex settings for your system in Scriptable Object and leave it to some game designer to deal with it. This is rude. Try to pull this complexity downward into your module. If you leave the complexity in the scriptable object, you will find out at some point that it will hurt you. May that be corrupt objects, which happen some times, or having issues merging things in Git. Try to put only high-level parameters in the config if they cannot be determined by some other system automatically. A quick example that comes to mind, and one I have used before is to have some settings that indicates how many concurrent download requests your app can make. Because, in some content-heavy game, which has to download lots of assets like images, audio, video or models, you don’t want to clog up that bandwidth.

But then again, use discretion when pulling complexity downward; it’s an idea that can easily be overdone. John has a very nice rule for determining whether you should pull down complexity and it goes as follows: “Pulling complexity down makes the most sense if (a) the complexity being pulled down is closely related to the class’s existing functionality, (b) pulling the complexity down will result in many simplifications elsewhere in the application,
and (c) pulling the complexity down simplifies the class’s interface. Remember that the goal is to minimize overall system complexity.”

Prof. Ousterhout also ends the chapter with a very nice quote: “When developing a module, look for opportunities to take a little of extra suffering upon yourself in order to reduce the suffering of your users.”

Thanks for suffering together with me and see you next time!

#end

01010010 01110101 01100010 01100101 01101110.