Abstract Base Class w/o Polymorphism

Why would you have an abstract base class defining an interface for a library where there is only one (always 开发者_运维知识库and forever) derived class?

---

You may want to swap out the implementation for something like Unit Testing

---

One reason why you would do this is for testability. It is much simpler to test dependent objects when their dependencies are defined as interfaces. This give the easy ability to mock or stub.

---

To violate the reused abstraction principle.

In short, don't do this.

Those who say "for testing" are overlooking that you can just replace

Base < - > Derived
Base < - > DerivedForMockingAndTesting

with

Derived < - > DerivedForMockingAndTesting    

That is, let your existing implementation Derived serve as the "abstraction" to be mocked out and tested in unit testing.

---

If you can be 100% certain that there will always be only one and exactly one derived class? Not much reason. BUT: In reality you hardly will be 100% certain of anything and surely not the future of your code.

---

You may find the need for different versions of that class to be binary compatible. You may also find that for other reasons, you wish to encapsulate the definition of the class- for example, because the definition requires a header which has poor macros, and that kind of thing, or the header containing what's necessary to define the class has a very long compile time.

For example, I wrote a class to encapsulate the features offered by my operating system- for now, things like dynamic loading and creating a window. Even though there'll only ever be one implementation for one compile target (Windows, etc), I chose to use a run-time abstraction, because I wanted to guarantee that the rest of my code never saw a platform-specific header, and the Windows header is full of so many macros and stuff, that I didn't want them leaking out.

---

The most obvious reason would be to be able to put the class' implementation in a source file, and not in a header. All that is exposed in the header is the abstract base class (and a factory function necessary to construct it, but this could be a static member). This avoids having to include the header files for any member data; the pimpl idiom is more idiomatic in C++ for this, but using abstract classes like this is far from unknown, and works fairly well as well.