C++ Inheritance – How to Avoid Redundant Code

cinheritance

Say I have a Base class called Car and it has 3 derived classes say Ford, Honda and Audi.

The issue is, all three derived classes have exactly same code but minor difference in calling member functions of their respective engines (these engines have separate class).

For example, Ford class calls code which is exactly same as other two classes but do call something like ford_engine-> start(), ford_engine->clean() etc.

//ly  honda  calls   honda_engine->start()   honda_engine->clean();

//ly  Audi calls audi_engine->start()  audi->clean();

Now here the issue is, it has redundant code in all three places with minute difference. How can I have code at one place, most probably in base class and all derived classes use same code?

Best Answer

The idea is to add a read only protected member variable (i.e. a protected property) engine to your superclass. Then, redefine the accessor in the subclasses to return the proper engine instance. Your code become this->getEngine()->start() and so on.

Related Solutions

Object-Oriented Design – Practical Differences Between Prototypal and Classical Inheritance

Recent blog post about JS OO

I believe what your comparing is classical OO emulation in JavaScript and classical OO and of course you can't see any difference.

Disclaimer: replace all references to "prototypal OO" with "prototypal OO in JavaScript". I don't know the specifics of Self or any other implementation.

However prototypal OO is different. With prototypes you only have objects and you can only inject objects into other objects prototype chain. Whenever you access a property on an object you search that object and any objects in the prototype chain.

For prototypal OO there is no notion of encapsulation. Encapsulation is a feature of scope, closures and first class functions but has nothing to do with prototypal OO. There is also no notion of inheritance, what people call "inheritance" is actually just polymorphism.

It does however have polymorphism.

For example

var Dog = {
  walk: function() { console.log("walks"); }
}

var d = Object.create(Dog);
d.walk();

Clearly d has access to the method Dog.walk and this exhibits polymorphism.

So actually there is a big difference. You only have polymorphism.

However as mentioned, if you desired to do so (I have no idea why you would) you can emulate classical OO in JavaScript and have access to (restricted) encapsulation and inheritance.

Should I test inherited methods

I'd take the pragmatic approach here: If someone, in the future, overrides Manager::getMail, then it is that developer's responsibility to provide test code for the new method.

Of course that's only valid if Manager::getEmail really has the same code path as Employee::getEmail! Even if the method is not overridden, it might behave differently:

Employee::getEmail could call some protected virtual getInternalEmail which is overridden in Manager.
Employee::getEmail could access some internal state (e.g. some field _email), which can differ in the two implementations: For example, the default implementation of Employee could ensure that _email is always firstname.lastname@example.com, but Manager is more flexible in assigning mail addresses.

In such cases, it is possible that a bug manifests itself only in Manager::getEmail, even though the implementaion of the method itself is the same. In that case testing Manager::getEmail separately could make sense.

Best Answer

Related Solutions

Object-Oriented Design – Practical Differences Between Prototypal and Classical Inheritance

Should I test inherited methods

Related Topic