Skip to main content

Avoid assumptions in infrastructure code

A few days back, while reviewing some code I came across what I considered to an over abundance of assumptions in infrastructure code. Such assumptions in infrastructure code can make software buggy and difficult to change.

Let me first explain what I mean by infrastructure code. Frameworks always have interactions that we use when we extend their classes. For example if you have used Struts, then the custom action classes we create, use Strut's infrastructure code from the ActionServlet and the Struts RequestDispatcher. These classes call methods which are overriden by our custom classes, thus allowing our code to get called.

Even when we do not use such frameworks, there are lots of places where we have hand written infrastructure code in our projects. Typically these are methods in base classes that are invoked as part of a use case. These methods will do a bunch of things that are determined by reading configuration files, decoding the request that invoked them, and perhaps other factors. While doing their stuff they also invoke base class abstract methods which has been overriden by other classes. This is almost a mini-framework. Unknowingly we all have such mini frameworks in our code. The stuff that is done by methods in the base classes is what I refer to as infrastructure code.

When we have such code, it is good to be careful, not to make too many assumptions. Because if in the future any of these assumptions change, then we may either have to override these methods in subclasses (creating difficult to read and difficult to test code), or we will have to change all the classes that are coupled with that infrastructure.

It is best to keep infrastructure code simple, and as assumption free as possible. One idiom which results in a lot of assumptions, is pushing common functionality to base classes. This does create reusable code, but it silently creates an assumption that this is what all subclasses will need. If a bug is introduced in such code, or if the assumption no longer holds true, it affects large parts of the software. If that assumption becomes false, then we either have to override base class methods in those subclasses in which that assumption does not hold true, or we have to change the base class interactions.

Overriding base class methods, is fine, but if overdone, it can lead to extremely difficult to understand classes. Such classes are also difficult to refactor because even a small change affects a lot of other classes, thus making even a small refactoring a large task.

Changing base class methods is quite a beast, which I am sure everyone will agree.

Because of these reasons, that I prefer to avoid pushing common functionality into base class methods, especially when the base classes are part of infrastructure code. Instead I prefer to factor out the common functionality into helper and utility classes and achieve reuse by composition.

Comments

Anonymous said…
Hi all,

I am working for a software integrator company. My projects includes working on Java and Ruby on Rails and Ajax. I think Web Services is really cool. We also recently have to now work on REST and they are talking about mashups and Struts. Can anyone tell me if there are some good training or conferences so that me and my team members can get to speed with these technologies. Learning from books is not my cup of tea, even not when I was doing engineering ;)

All the help that group members can provide in this regard is much appreciated.

Thanks,
Vaibhavi
Parag said…
I have also found Parleys.com to be a good online learning resource for such topics.

They publish videos from software conferences, and most of them are pretty good.

Popular posts from this blog

Commenting your code

Comments are an integral part of any program, even though they do not contribute to the logic. Appropriate comments add to the maintainability of a software. I have heard developers complain about not remembering the logic of some code they wrote a few months back. Can you imagine how difficult it can be to understand programs written by others, when we sometimes find it hard to understand our own code. It is a nightmare to maintain programs that are not appropriately commented. Java classes should contain comments at various levels. There are two types of comments; implementation comments and documentation comments. Implementation comments usually explain design desicisions, or a particularly intricate peice of code. If you find the need to make a lot of implementation comments, then it may signal overly complex code. Documentation comments usually describe the API of a program, they are meant for developers who are going to use your classes. All classes, methods and variables ...

Inheritance vs. composition depending on how much is same and how much differs

I am reading the excellent Django book right now. In the 4th chapter on Django templates , there is an example of includes and inheritance in Django templates. Without going into details about Django templates, the include is very similar to composition where we can include the text of another template for evaluation. Inheritance in Django templates works in a way similar to object inheritance. Django templates can specify certain blocks which can be redefined in subtemplates. The subtemplates use the rest of the parent template as is. Now we have all learned that inheritance is used when we have a is-a relationship between classes, and composition is used when we have a contains-a relationship. This is absolutely right, but while reading about Django templates, I just realized another pattern in these relationships. This is really simple and perhaps many of you may have already have had this insight... We use inheritance when we want to allow reuse of the bulk of one object in other ...

Planning a User Guide - Part 3/5 - Co-ordinate the Team

Photo by  Helloquence  on  Unsplash This is the third post in a series of five posts on how to plan a user guide. In the first post , I wrote about how to conduct an audience analysis and the second post discussed how to define the overall scope of the manual. Once the overall scope of the user guide is defined, the next step is to coordinate the team that will work on creating the manual. A typical team will consist of the following roles. Many of these roles will be fulfilled by freelancers since they are one-off or intermittent work engagements. At the end of the article, I have provided a list of websites where you can find good freelancers. Creative Artist You'll need to work with a creative artist to design the cover page and any other images for the user guide. Most small to mid-sized companies don't have a dedicated creative artist on their rolls. But that's not a problem. There are several freelancing websites where you can work with great creative ...