在这种C ++设计方案-OOPS中，如何避免油脂过多/污染的接口？

Question

We are writing a generic middleware for the gadget- DTV. We have a module called ContentMgr, which is a base class. Now, for the different customer needs, we have the VideoconContentMgr ( for instance)- which is derived from ContentMgr.

class ContentMgr
{
  public:

virtual void setContent()
{
  cout<<"Unused function";
}

};

class VideoconContentMgr: public ContentMgr
{
  virtual void setContent()
  {
     cout<<"Do some useful computation;
  }

};

client code - based on the product type - the

/** if the product is generic **/ ContentMgr *product = new ContentMgr();

/** If the product is videocon **/ ContentMgr *product = new VideoconContentMgr();

My question is according to the Interface Segregation Principle - One should avoid fat/polluted interfaces. How can I avoid the polluted method - setContent() here. For the generic product,setContent() is not useful. However, for the videocon product it is useful. How can I avoid the fat/polluted method setContent()?

Answer 1

For the generic product, setContent() is not useful. However, for the videocon product it is useful.

One solution is to keep the member function where it is useful - put it into VideoconContentMgr only, and use it in the context specific to the VideoconContentMgr subtype:

/** if the product is generic **/ ContentMgr *product = new ContentMgr();

/** If the product is videocon **/ {
    VideoconContentMgr *vcm = new VideoconContentMgr();
    vcm->setContent();
    ContentMgr *product = vcm;
}

If the usefulness of the member function specific to a subclass extends past the initialization time, use a visitor -like approach. Subclass-specific code remains bound to subclasses, but now you add a visitor that does nothing for a generic class, and calls setContent() on VideoconContentMgr class:

struct ContentMgrVisitor {
  virtual void visitGeneric(ContentMgr& m) {};
  virtual void visitVideo(VideoconContentMgr& vm) {};
};

struct ContentMgr
{
  virtual void accept(ContentMgrVisitor& v)
  {
    v.visitGeneric(this);
  }
};

struct VideoconContentMgr: public ContentMgr
{
  virtual void setContent()
  {
     cout<<"Do some useful computation;
  }
  virtual void accept(ContentMgrVisitor& v)
  {
     v.visitVideo(this);
  }
};

Now a client who wants to call setContent can do it from a visitor:

class SetContentVisitor : public ContentMgrVisitor {
    void visitVideo(VideoconContentMgr& vm) {
        vm.setContent();
    }
};
...
ContentMgr *mgr = ... // Comes from somewhere
SetContentVisitor scv;
mgr->accept(scv);