#begin

Hey and welcome back for another blog about A philosophy of software design. Today we are diving into chapter 6 General-purpose modules are deeper. Let’s have a look!

General-purpose modules are deeper

In software design you often need to make a choice whether to implement code special – or – general-purpose. General-purpose code is, generally, more difficult to write and will take you some more time to think about and implement. This comes back to the tactical and strategic mind-sets we discussed a bit earlier. In a tactical mindset, you might implement a feature in a special purpose sense, fully focused on the task at hand to achieve it’s goal. But with a more strategic mindset you might implement the feature anticipating future changes or reusability purposes. But sometimes, it’s a trap! To implement something too general purpose. Because in some cases, implementing something too general purpose might not solve the problem you have today in a simple way. But then again, if you make it to special purpose, you might quickly find out when you want to reuse that logic, but you can’t. So in this next chapter we will discuss how to find a proper balance between general and special purpose code.

John says to make modules, “somewhat general purpose” and whit that statement he means that the module’s functionality should reflect what you need today but it’s interface should not. The interface of the module should be general and easy enough to be reused in multiple use-cases. So the word “somewhat” means; don’t get carried away and build something so general-purpose that iit is difficult for you current needs.

The most important take-away from this is that, general purpose module often result in simpler, and deeper modules than special purpose modules. Keep that in the back of you mind while developing a game and try to keep code reusable.

He also says that general purpose modules lead to better information hiding and thus less leakage. This seems kind of obvious right? Something general purpose will definitely require less in-depth or domain knowledge than some special purpose module. It’s just in the nature of the animal. John than sums up a couple of questions you could ask yourself while designing your game:

“What is the simplest interface that will cover all my current needs?” This comes down to keeping the interface small and simple to use. How can you expose just the functionality you need for your use-case today without leaking information. A simple example is the following; if you have an interface that requires lot’s of arguments in functions then you are probably not simplifying things.

Secondly he asks: In how many situations will this method be used? This might be a difficult question to answer since you might not be able to predict this quickly but if you method is currently designed and implemented for a single special-purpose usecase this might be a red flag again and you might want to see if you can find a more general purpose solution to your problem.

Third: Is this API easy to use for my current needs? This is a question you might ask yourself to determine if you have made some API too general purpose and you haven’t gone totally overboard. If you need to write too much code in order to use your class API correctly, that might be a red flag that the API is far to general purpose.

But to wrap this chapter up: general-purpose interfaces have many advantages over special purpose interfaces like: Being simpler, with fewer methods and deeper. They provide a nicer separation between classes while special-purpose interfaces often have dependencies and thus leak information between them. So making classes general purpose will reduce complexity of your system.

That’s it for this short chapter, till next time!

#end

01010010 01110101 01100010 01100101 01101110.