Dec 19, 2008

Risk of inheritance

Inheritance is one of the basics in any object oriented language but you always should think a lot before use it in your code. Of course inheritance is very useful when you design your code for it, use abstract classes, template method design pattern, create different implementations overriding well defined protected methods and so on. But in some cases inheritance may make damage to your application in future very silently.

Imagine situation when you want to add some behavior to class and decided to override its public methods in the child class. The following hidden issues are waiting for you:

* You don't know how this method is used and how it will be used in future in code of the parent class. Your changes may cause unpredictable behavior.
* You want to control some access points of the parent class, but in future some more points can be added and your code will fail in unpredictable time interval.
* Overridden methods will be removed in future, deprecated or change their access level.
* Some other issues depending of concrete scenario.

To avoid most of these issues use composition instead of inheritance. Create new class and declare needed behavior by implementing the same set of interfaces such a basic class. May be you need only some of them, so you can localize your needs and have easier implementation saving time for support. Then implement some methods and delegate all other to the instance of basic class.

Composition has its own disadvantages when basic class is too large or creation of the instances is too complicated, then you need to duplicate a lot of code or logic. IDE or other automation tools can help you with generation of such kind of code.

But what to do if basic class doesn't implement any interfaces and declared abstract? In this case you have to protect yourself from as many issues as possible. Create unit tests to control basic class methods and validate if all of them are known by you. These tests will notify you if basic class was changed so you need to look at new implementation and may be make changes in code or tests. To access information about declared methods use reflection API or some open source libraries that simplify access to this information. But think before if you really need inheritance in this case (if class was not designed for inheritance) and try to avoid it if possible. Develop with pleasure!

Crisis in action

As far as you know in many countries economical crisis came and many "experienced" people was fired in IT market. But crisis makes a good job for some companies. I want to share my experience in interviewing one of such "experienced" guys. This person has a lot of practical experience with Java language at all levels from core to web. After some general questions I proposed following interface declaration:

public interface I {
int b = 5;
void a();
}

The question was if this declaration is correct. A received the following answer: "No. You need to change it to be correct." Here is what he wrote:

public interface I {
int b = 5;
private void a();
}

The explanation was great: "Instead this method will have visibility only in the package". The next question was about difference between abstract class and interface. The answer makes me smile: "The advantage of abstract class is that I can declare method in it and don't think about it anymore". Imagine how hard is to think about method in all other cases. :) "And why do you ask all these stupid questions? All this is so simple and doesn't matter" - he continued. After that phrase interview was finished.

So, do you want your code to be developed by such guys? If no be aware of crisis. And develop with pleasure...