Otaku, Cedric's weblog

I avoid this kind of problems by adding a protected method for overriding in subclasses, if needed. This protected method is invoked in the public (main) one.
Something like

public vois setUp()
{
// code which must be executed even in subclasses
// ...and
setUpProtected();
}

Now, a subclass can override setUpProtected() which is empty here.
Analogous mechanism used in Swing for paintComponent() calls

Sorry Cedric-,
You twisted the words of James Gosling. Here are the appropriate extracts from the interview - read for yourself:
-----------------------------
"
A delegation-only language
Venners: When asked what you might do differently if you could recreate Java, you've said you've wondered what it would be like to have a language that just does delegation.

Gosling: Yes.

Venners: And we think you mean maybe throwing out class inheritance, just having interface inheritance and composition. Is that what you mean?

Gosling: In some sense I don't know what I mean because if I knew what I meant, I would do it. There are various places where people have completed delegation-like things. Plenty of books talk about style and say delegation can be a much healthier way to do things. But specific mechanisms for how you would implement that tend to be problematic. Maybe if I was in the right mood, I'd blow away a year and just try to figure out the answer.

Venners: But by delegation, you do mean this object delegating to that object without it being a subclass?

Gosling: Yes -- without an inheritance hierarchy. Rather than subclassing, just use pure interfaces. It's not so much that class inheritance is particularly bad. It just has problems.

...
Venners: Inheritance meaning class extension?

Gosling: Class extension. I tend to use classes a lot more than interfaces, and I'm not sure why..."

I've also encountered the problem with forgetting to call the setUp method in derived TestCases. But it's a very small problem: my tests fail, usually with a NullPointerException, I realise I forgot to call super.setUp(), I fix it, my tests pass. That's what tests are for.

You need to declase setUp as final like.

public final void setUp()
{
// code which must be executed even in subclasses
// ...and
setUpProtected();
// More code if needed
}

public abstract setUpProtected();

Final? Are you kidding me? Every time I run into a "final" method, I curse the author to a life of barren seed, because that is what final does to their code. Final is yet another example of one developer choosing to believe that they are wiser than all those who follow them.

Design well. Document well. Implement well. Those who choose to extend blindly, let them twist on their own rope.

When I run into a method that's final and I need to override it, I delete the "final" keyword and keep going. What do you do?

Oh, wait, you don't have the source? Then how do you know it's safe to override?

What do you mean, safe to override? Do you think the base class uses reflection to make sure that someone hasn't extended a particular method, then throws an exception?

Inheritance is natural, and it is powerful. Like many other things in programming, it requires some intelligence and good practices to use effectively.

If people can't even understand and master inheritance, then I'm really worried about them digging into the whole new AOP can of worms.

Cameron,

I totally agree. Can't be said better.

Interface (type) inheritance and implementation inheritance are two completely different things. The downside of implementation inheritance is obviously the very tight coupling between superclass and subclass. Delegation/composition allows the classes to remain loosely coupled via an interface, so that the implementations can evolve independently without breakage, as long as the software contract remains stable. Implementation inheritance does not allow for such a well-defined software contract to exist between the classes, so this coupling leads to fragility.

I would still use implementation inheritance opportunistically. As a rule of thumb, I'd probably restrict its use between classes in the same package, since they generally represent units, which are inseparable, so the higher coupling isn't such a big deal. It's probably even ok across packages that always live together in the same jar, because the jar is always used as a module. The wider the network of tightly coupled classes, the more spaghetti-like the code, and the more difficult it is to evolve (e.g., replace a superclass with a better one).

I would probably avoid implementation inheritance across classes in different jars. In fact, I would try to keep the classes from different jars completely isolated by interfaces. Being unable to evolve an implementation for fear of massive and subtle (not explicitly defined by contract) breakage is one of the biggest nightmares, as software grows larger with age.

Ben Eng-,
You are 100% correct! I just do not understand the others, which allow liberal use of (implementational)inheritance in their exported APIs. I guess, old C++ habits :-)

Peace,
Hristo

I agree as much initialization logic as possible should be in constructors. I thought it was worth mentioning when I discussed such with a collegue of mine, who programs largely in embedded systems using c++, he quickly stated he does *does not* want complex initialization logic happening at construction time, because if something bad happens (exception, whatever) you could end up with a partially allocated object, which could cause problems when the object's destructor is called.

Luckily in java we don't have to worry so much about that :)

jft