Utopia interface and realization of separation technology

"Imperfect C + +" shows a technology called "Bolt", however, the discussion in this book is not deep enough. Of course, I also believe that Matthew is intentional, so that our "three-way" (Matthew claiming to be two-way merchants) can also achieve a little sense of achievement.

Consider such an interface design:

struct IRefCount;
struct IReader : public IRefCount;

To implement an interface in reader:

!--[If!supportemptyparas]--> class Reader:public Ireader;

In the above inheritance structure, Irefcount is a structured class that implements reference counting, and in fact it has nothing to do with the domain logic part ireader. We intend to build a set of tools to manage the object lifecycle and to help implement exception-safe code (for example, smart pointer) based on Irefcount. Now consider the implementation of reader, reader, in addition to the need to implement Ireader interface, but also must implement Irefcount interface. It all seems logical, let's keep looking at the following design!--[if!supportemptyparas]-->:

struct IWriter : public IRefCount;
＜!--[if !supportEmptyParas]--＞ class Writer : public IWriter;

Now to consider the implementation of writer, like reader, writer in addition to implementing the Iwriter interface, but also need to implement Irefcount interface. Now, let's look at how the Irefcount is defined:

struct IRefCount {
virtual void add() = 0;
virtual void release() = 0;
virtual int count() const = 0;
virtual void dispose() = 0;
virtual ~IRefCount(){}
};

The implementation of Irefcount in reader:

virtual void add() { ++m_ref_count;}
virtual void release() {--m_ref_count;}
virtual int count() const{return m_ref_count;}
virtual void dispose() { delete this;}
…
int m_ref_count;

Similarly, in the implementation of writer, the same code is included, which violates the dry principle (Don ' t Repeat yourself). Moreover, as the classes in the system increase, everyone realizes that this part of the code needs to be reused. A way to work is to put Irefcount implementation code directly into the Irefcount, through inheritance, derived classes do not have to implement Irefcount again. Let's take a look at the implementation of Dispose:

virtual void dispose() { delete this;}

Here, delete is used to destroy the object, which means that reader must be allocated on the heap before it is possible to properly manage the lifecycle of the object through Irefcount, and we can also override the Dispose method and implement Dispose in reader as follows:

virtual void dispose() { }

However, this brings a problem, reader can not be allocated on the heap! If you are ruthless enough, of course, you can solve the problem as well:

class HeapReader : IReader;
class StackReader : HeapReader{ virtual void dispose() { } };

The question is, is Stackreader a heapreader? For code reuse, we completely ignore the concept. Of course, if you like me, you value maintenance concepts, so do it:

class HeapReader : IReader;
class StackReader : IReader;

In this way, the implementation of Ireader will be repeated, and violate the dry principle, waiting to be the future maintenance engineer Curse it! Perhaps, the maintenance engineer is 3 months after you. If this really solves the problem, then it is acceptable, and soon we have a new interface:

struct IRWiter : IReader, IWriter;
class RWiter : public IRWiter;

Consider the semantics of Irefcount: It is used to record the reference count of the object in which it is located. Obviously, the irefcount I get from either branch of Ireader and Iwriter should all be the same reference count effect. But now that the inheritance tree has two irefcount instances, we have to reload it again in the Rwiter. Thus, the two instances inherited from Ireader and Iwriter are invalidated, and we may have wasted 8 bytes. To solve this problem, we can also continue on another dangerous path, that is, virtual inheritance:

struct IReader : virtual public IRefCount;
struct IWriter : virtual public IRefCount;

Remember the advice the gurus gave-"do not store data members in virtual base classes." "So what's the problem, we don't have to worship the master blindly," you must have heard that advice. If the Masters can't convince these people, then neither can I. As a result, we further provide default implementations in all interfaces, including Ireader and Iwriter.