How can I inheriting from a concrete class in Perl?

Question

Our software represents each device as a concrete class. So let's say I have a class named Cpu-Version-1, which is derived from a abstract baseclass called Device. Now, the CPU vendor wants to release the economic version of this CPU ( Cpu-Version-2 ), which is a feature reduced version of Cpu-Version-1 (obviously for a lower price ). 90% code of Cpu-Version-2 is same as of Cpu-Version-1, but the remaining 10% code is no longer same. i.e. these are the features that have been removed in Cpu-Version-2 and so I should no longer represent it.

Now what would be the best way to design this class? I could inherit Cpu-Version-2 from Cpu-Version-1 (even though the inheritance is imperfect, since these two devices are peers). This would force me to override a lot of methods of cpu-version-1 to do nothing ( which looks ugly and somehow doesn't feel right). Also I don't think I could change the baseclass (Cpu-Version-1 or it's base) since the code is already in production and requires lot of approvals and justification. How would you make this design decision if you were me?

How do we make Cpu-Version-2 as much reusable and maintainable? Is there any OOP principles that you would follow? Or is it better tradeoff to take the easy wayout and override all the non-applicable methods of Cpu-Version-1 to do nothing? I code in object-oriented Perl.

Answer 1

I think one of the major stumbling blocks that impedes the progress of object-oriented programming projects is the common misconception that inheritance is the only way to compose new classes from multiple sources. But inheritance in general is actually a pretty sucky model, and only really works for things that can be neatly taxonomized in a perfect hierarchy. As you have discovered, the real world often doesn't work that way.

It sounds like inheritance is not a good model for this problem. Fortunately, there are other models available for constructing classes in Perl.

With Moose, you can use roles for composing classes with a combination of things they "do" without having to create a complicated (and in this case, ill-suited) inheritance hierarchy.

If you don't want something as heavy-duty as Moose, there are also simpler options like mixin.

Another option that may interest you is prototype-based composition, as with Class::Prototyped. This is still hierarchy-based, but gives you a lot more flexibility by allowing you to mess with individual instances and then use those as the prototype for new instances. This is how OO is done in languages like Javascript and Self.