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

My HSQLDB schema inspection story

This is a simple story of my need to inspect the schema of an HSQLDB database for a participar FOREIGN KEY, and the interesting things I had to do to actually inspect it. I am using an HSQLDB 1.8 database in one of my web applications. The application has been developed using the Play framework , which by default uses JPA and Hibernate . A few days back, I wanted to inspect the schema which Hibernate had created for one of my model objects. I started the HSQLDB database on my local machine, and then started the database manager with the following command java -cp ./hsqldb-1.8.0.7.jar org.hsqldb.util.DatabaseManagerSwing When I tried the view the schema of my table, it showed me the columns and column types on that table, but it did not show me columns were FOREIGN KEYs. Image 1: Table schema as shown by HSQLDB's database manager I decided to search on StackOverflow and find out how I could view the full schema of the table in question. I got a few hints, and they all pointed to

Fuctional Programming Principles in Scala - Getting Started

Sometime back I registered for the Functional Programming Principles in Scala , on Coursera. I have been meaning to learn Scala from a while, but have been putting it on the back burner because of other commitments. But  when I saw this course being offered by Martin Odersky, on Coursera , I just had to enroll in it. This course is a 7 week course. I will blog my learning experience and notes here for the next seven weeks (well actually six, since the course started on Sept 18th). The first step was to install the required tools: JDK - Since this is my work machine, I already have a couple of JDK's installed SBT - SBT is the Scala Build Tool. Even though I have not looked into it in detail, it seems like a replacement for Maven. I am sure we will use it for several things, however upto now I only know about two uses for it - to submit assignments (which must be a feature added by the course team), and to start the Scala console. Installed sbt from here , and added the path

Five Reasons Why Your Product Needs an Awesome User Guide

Photo Credit: Peter Merholz ( Creative Commons 2.0 SA License ) A user guide is essentially a book-length document containing instructions for installing, using or troubleshooting a hardware or software product. A user guide can be very brief - for example, only 10 or 20 pages or it can be a full-length book of 200 pages or more. -- prismnet.com As engineers, we give a lot of importance to product design, architecture, code quality, and UX. However, when it comes to the user manual, we often only manage to pay lip service. This is not good. A usable manual is as important as usable software because it is the first line of help for the user and the first line of customer service for the organization. Any organization that prides itself on great customer service must have an awesome user manual for the product. In the spirit of listicles - here are at least five reasons why you should have an awesome user manual! Enhance User Satisfaction In my fourteen years as a