Harshdeep 2.0

June 21, 2007

Reusing High Level Modules – Dependency Inversion Principle

Filed under: Design Patterns, Dev, Geek, Programming — harshdeep @ 8:14 am

It is easier to make a low-level module reusable, than a high level module. Firstly, a low-level module generally has clearer goals (do one thing and do it right), and wider usability (number of people who need a generic stack is much more than those who need a document indexer). Secondly, a low-level module has less dependencies on other modules. When one moves a module from one application to another, one also needs to move all the modules that it depends on and, since dependency is transitive, also the modules that those modules depend on and so on. So, higher the efferent coupling of a module, harder it is to reuse it.

Note that we are talking about reusing a module and not just copying chunks of code. Code copying is not code reuse.

code copying … comes with a serious disadvantage: you own the code you copy! If it doesn’t work in your environment, you have to change it. If there are bugs in the code, you have to fix them. If the original author finds some bugs in the code and fixes them, you have to find this out, and you have to figure out how to make the changes in your own copy. Eventually the code you copied diverges so much from the original that it can hardly be recognized. The code is yours. While code copying can make it easier to do some initial development; it does not help very much with the most expensive phase of the software lifecycle, maintenance.

I prefer to define reuse as follows. I reuse code if, and only if, I never need to look at the source code (other than the public portions of header files). I need only link with static libraries or include dynamic libraries. Whenever these libraries are fixed or enhanced, I receive a new version which I can then integrate into my system when opportunity allows.

Now, to make my high level component reusable, I need to remove it’s dependencies on low-level modules. This is one of the motivations behind Dependency Inversion Principle put forward by Robert C. Martin in another of his brilliant papers on Design Patterns.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.

This predicament is absurd! It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way.

Moreover, it is high level modules that we want to be able to reuse. We are already quite good at reusing low level modules in the form of subroutine libraries. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

He defines the Dependency Inversion Principle as

a) High level modules should not depend upon low level modules. Both should depend upon abstractions.

b) Abstractions should not depend upon details. Details should depend upon abstractions.

    Here’s an example from the same paper. In the traditional layered design as below, a change in the lowest level Utility Layer can affect the highest level Policy Layer.

    Instead of letting each layer depend directly on the one underneath it, I can make each of the higher level layers use the lower layer through an interface (abstract class) that the actual layer implements (derives from).

    Now none of the higher level layers will be affected if any of the lower level layers change, as long as they keep abiding to their respective interfaces. If I switch to a third party library for any of the lower level layers, I can write an Adapter to make it confirm to its interface, thereby not affecting the higher level layer at all.

    In many simple cases, DI can also be achieved through callbacks. A very common example is when a module provides APIs to allow the application to set its own memory allocation and de-allocation callbacks. The application may do this when it wants to use a heap optimized for small memory allocations, or if it wants to keep track of total memory allocated.

    However, I think there are cases when it’s alright if you don’t follow DIP.

    1. Lower-level module is highly stable. If you know that the lower-level module won’t change much during the life time of the depending module, and you are never going to have to replace it, even when the depending module is reused in another application, there is no harm in depending directly on it.
    2. Lower-level module is highly specific. Again, if you’ll never have to replace the lower-level module with another, you can depend directly on it.
    3. Performance is crucial. Use of abstract classes and virtual functions has a performance penalty. So it’s not advisable for the performance critical parts of the application. However, one can consider using plain function callbacks to achieve DI in such cases, as in the allocation/de-allocation routine example above.

    June 26, 2006

    Bumptop 3D Desktop Prototype

    Filed under: Geek — harshdeep @ 6:21 am

    An ultracool 3D desktop prototype inspired from physical desks.

    It's the work of Anand Agarwal, an MSc student in the University of Toronto

    March 30, 2006

    Hacking Unjumble

    Filed under: Geek — harshdeep @ 8:40 am

    One thing I recently discovered about myself is that I suck at Unjumbling words. I discovered this the hard way when Prasun challenged me for a game. A chat bot would give us a jumbled word and whoever unjumbled it first got the points. I was losing 100:10 when I called for time-out. Desperate times call for desperate measures. After some googling I found this text file on the web containing (almost) all english words. After that all I had to do was write a simple program that would take the jumbled letters and search the unjumbled word from the wordlist for me. Now, I can safely say that I can beat Prasun sometimes.

    If you wanna rock at Unjumble without any moral hesitations towards cheating and are too lazy to write the program yourself, feel free to drop a message 🙂 You can also use a web service, but that's slower.

    March 2, 2006

    Web Applications: Hype + Buggy Software = Disaster

    Filed under: Geek, Internet — harshdeep @ 8:12 am

    Popular wisdom for Web Applications is to make frequent releases with limited features, test the market/get feedback, put more features, get more feedback, … This strategy works because

    1. You can release the application sooner than later. Competitors have less chance of sniffing out your idea and releasing the duplicate even before the original.

    2. You don’t need to worry about the users installing the updates. Everyone automatically gets the latest release as soon as you update the application on your servers.

    3. User feedback/surveys let you better filter and prioritise the features you want to put in your application.

    But frequent releases do not give the developers the liberty of releasing buggy applications – even in the beta stage, web applications can not afford to have serious bugs if they want the first set of customers (generally the trend setters) to come back. Greater the hype, higher the risk – more people will check out the application and, if it’s buggy, more people will know about it and few of them will ever come back.

    Case in point – BlogMad

    I’d read about it on some popular blogs, so I’d registered myself to be intimated about the public beta. I got their mail today morning, and when I tried it out, it simply wasn’t working. They should have avoided this at any cost.

    Update: After the initial hiccups, BlogMad seems to be working fine now.

    Update 2: Anshul reported a (minor?) BlogMad bug in the comments section – “I tried taking part in the lottery on BlogMad and got myself 2 tickets. However when I refreshed the page, I had been issued 4 tickets and not 2. Not very pissing off but nonetheless irritating.”

    Create a free website or blog at WordPress.com.