Base Class Logic – Implementing Common Logic in Object-Oriented Design

mockingobject-orientedobject-oriented-designunit testing

Background

In the documentation of a project I'm working on I came across the following sentence which immediately triggered an alarm for me:

when having several concrete classes that inherits from the same base class, logic which is common for all sub classes should NOT be implemented in the base class.

This is a pretty bold statement which kind of conflicts with everything I think of OOP.

The reason stated was testability. It said that when writing unit tests, if a common logic is implemented in the base class, it will be tested multiple times for each concrete sub class and cannot be mocked out.

Question

Where or how can one implement a common logic for multiple sub classes so it can be easily mocked when they are being tested?

Best Answer

You stumbled on one of the Bigger problems that tends to get swept under the rug in unit testing/TDD discussions. Well designed code from an object oriented perspective is generally hard to unit test, code that is easy to write unit tests for usually is compromising some paradigms of object oriented design.

Most approaches to unit testing tend to drive towards a design that makes unit testing easier, which isn't bad depending on what rules you bend/break. These designs tend to over expose methods so they can be more easily isolated, using interfaces or utility classes to handle common code.

Dependency injection is one of the more popular ways to handle these situations. Here is a pretty simple example in C#. Essentially rather than inheriting directly from a base class, each class will instead implement an interface that is dependent upon an object that handles the common operations. This way you can simply pass MyMockedCommonClass instead of MyCommonClass in your unit tests. This also allows your code to still be pretty Object Oriented friendly.

Related Solutions

C# – Empty virtual method on base class VS abstract methods

In this case the base class should know nothing of SectionA. The derived class should implement the extra properties that that type needs.

For certain operations where another class needs to pull information out regardless of the type of document you will want that method on the base class ideally virtual with a basic implementation and allow derived classes to override it if needed (eg ToPlainText which would just output all the sections of a document would be on Document, FancyDocument can override the implementation to also output SectionA).

For instances where another class doesn't care about the type of document but does care if it has certain properties use interfaces. IDocument would have all the common sections and Document would implement it. IDocumentWithSectionA would inheerit IDocument and FancyDocument would implement that. This then lets you derive another NeitherFancyNorNotFancyDocument that has SectionA which can also implement IDocumentsWithSectionA.

Obviously You'd have more useful names than IDocumentWithSectionA but that depends on the usecase.

TL;DR use the abstract class for what should be common to all documents and some common functionality, use interfaces as the contract saying what a document has.

Object-oriented – Abstract base class with only protected members

If you're just using the base class as a way of sharing implementation between the two (or more) derived classes, and the base class doesn't represent an interface, then public inheritance is almost certainly a mistake.

One possibility would be to use aggregation (put the shared data into a helper class, and include an instance of that class in each "derived" class that needs it).

Another possibility would be to use private inheritance. Private inheritance is usually described as "is implemented in terms of". Where public inheritance needs to conform to the Liskov Substitution Principle (at least in a decent design), private inheritance carries no such requirement. With private inheritance, the derived class is 'aware' of its relationship to the base class, and can use implementation from the base class. That relationship is "hidden" from the outside world though, so there's not an implicit conversion from the derived class to the base class like there is with public inheritance.

class base { };

class D1 : public base { };

class D2 : base { };

int main() { 
    base *b = new D1; // no problem
    base *b2 = new D2; // won't compile
}

If you really insist, you can convert a pointer to the derived to a pointer to base--but you have to use a cast (and, interestingly, it has to be a C-style cast; none of the "new" C++ casts can really do this correctly¹).

For those who are tempted to dispute this: yes, a reinterpret_cast will appear to do the job correctly for some cases--but (to give only one counterexample) if you use multiple inheritance, it will only convert from derived to one of the base types correctly. Attempting to convert to another base type will produce bad results.