服务水平继承答案

【问题标题】：Service Level Inheritance服务水平继承
【发布时间】：2013-07-29 19:02:25
【问题描述】：

假设我们有两种服务模式。

ICommon接口
-action1()

Mode1Service 继承 ICommonInterface
Mode2Service 继承 ICommonInterface

两者都有相似的功能，所以有一个共同的接口（ICommonInterface）。那么为 ICommonInterface 提供实现的最佳方式是什么，是继承还是组合或任何其他方式？

1) 如果我们更喜欢组合的话，这不是纯粹的继承。通用逻辑将作为不同的辅助类。 Mode1Service 和 Mode2Service 必须遵守共同契约并调用这些帮助程序来提供实际的实现。
- 帮助类不需要单独使用。

2) 通过继承，我们将拥有一个 AbstractBaseModeService，它继承了由两个模式服务类继承的公共接口。同样，Mode1Service 和 Mode2Service 除了通用接口外，还有自己的接口。

我觉得继承更好，即使它只提供代码可重用性。有关如何处理此类情况的任何想法。

【问题讨论】：

标签： design-patterns inheritance service composition

【解决方案1】：

我也会喜欢这样的：

class CCommonFunctions
{
   public:
    // Some utility Functions
    void set_somefunctions() 
    {
    }
};

class ICommonInterface
{
  public:
    virtual void action() = 0;
  protected:
    CCommonFunctions *p;
};

class Mode1Service: public ICommonInterface
{
   public: 
     void action() 
     {
        p->set_somefunctions();
        ... 
     }
};

class ServiceMaker
{
 public:
   void setService(ICommonInterface *icip)
   {
       m_ici = icip;
   }
   void makeAction()
   {
       m_ici ->action();
       ...
   }  
 private:
   ICommonInterface *m_ici;
};

int main()
{
  ServiceMaker mk;
  ICommonInterface *ici = new Mode1Service;

  mk.setService(ici);
  mk.makeAction();
  ...
  ...
}

如果它适合你，请告诉我，我也为此使用了 Builder 模式。

【讨论】：

【解决方案2】：

第一件事，

我们是否应该保持对象干燥（不要重复自己），
这些实施是否应遵循共同合同。

我个人认为我们可以继续使用具有这些通用逻辑的接口和抽象方法，并让实现在任何需要的地方做自己的事情。这是默认方式。通过组合新对象将其作为辅助类或域对象从抽象类中提取出来也是不错的。

Saby 提供的示例与我将复制的示例相同。

免责声明：（可以考虑）
仅仅因为 Mode1Service 和 Mode2Service 有一些共同点，拉出一个公共接口 ICommonInterface 会很糟糕，因为引入了 coz 接口是为了使服务遵循一些结构。

【讨论】：