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.
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
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
They publish videos from software conferences, and most of them are pretty good.