I have a group of classes that extend a single abstract class. A subset of these classes need an identical implelmentation of one of the methods, another subset of the classes needs another implementation of the method, and a third subset requires yet another. In all there are about ten child classes, but only three possible implementations of one of the methods. (There are many other methods that the classes implement that have nothing in common.)
I'm trying to figure out the best way to accomplish this. I think what I would have done in C++ is multiple inheritance: create threee classes that implement only this method, then have the children inherit from the appropriate one of those three classes.
Is there a best practice for doing this in Java?
I was considering an intervening layer of three abstract classes, between the main abstract class and the children. Each of the the three inheriting from the main abstract class, and implementing the method in question. Then the children inherit from these threee. But what I don't like about that is what if another method comes along with a similar "grouping" behaviour, and it does not correspond to the three "middle tier" classes? That would get ugly
Is any of this making any sense? I'm writing in a hurry...
EDIT: So, 24 hours after asking my question I have received about a half dozen patterns to investigate. I'm not yet sure that they are all official design pattern names. But I'm going to look into each and then report back (and choose an answer as correct). The pattens suggested so far:
* Delegation
* Bridge
* Strategy
* Composition
* Decorator (if I was choosing on name alone, I choose this one)
I also need to add that the method that is being implemented needs access to nearly all of the private members of the class. So that will factor large in my choice.
Actually, I smell a Strategy pattern here.
You could have that method in the base class delegate to a Strategy that is passed in upon construction. Sub-classes just pass in any one of a set of Strategies as part of their construction. The Strategies themselves could be made available either outside the class, or internally as private classes. This may end up with less classes overall in your hierarchy.
That being said, there are additional smells here, even with my proposed solution. You may want to think at a higher level with interfaces (as mentioned by other solutions) and composition only with no inheritance. Over time I came to the conclusion the inheritance is NOT my friend. Nowadays I avoid it where possible.
Use delegation rather than inheritance. Have all the classes of a same group delegate to a common helper object to implement their method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With