solid测序列原理_SOLID Design：C ++中的接口隔离原理

solid测序列原理

我 小号覆盖整个院落egregation P rinciple在C ++中是第四次与目前的一系列坚如磐石的设计原则的最简单的设计原则。 SOLID设计原则专注于开发易于维护，可重用和可扩展的软件。 在本文中，我们将看到违反ISP的代码，这是ISP相同代码，准则和优势的解决方案。

顺便说一句，如果您还没有阅读我以前有关设计原则的文章，那么下面是快速链接：

1. S RP –单一责任原则
2. O CP –开放/封闭原则
3. L SP – Liskov替代原则
4. I SP –接口隔离原则
5. D IP –依赖倒置原则

您在本系列文章中看到的代码段是简化而不是复杂的。 因此，您经常看到我不使用诸如override，final，public（同时继承）之类的关键字只是为了使代码在大多数标准屏幕尺寸内紧凑且易用（大部分时间）。 我也更喜欢使用struct而不是class来保存行，因为有时不编写“ public：”，并且还错过了虚拟析构函数 ，构造函数， 复制构造函数 ，前缀std ::，故意删除了动态内存。 我也认为自己是一个务实的人，他希望以最简单的方式而不是标准的方式或使用术语来传达想法。

注意：

• 如果您直接在这里偶然发现，那么我建议您经历一下什么是设计模式？ 首先，即使是微不足道的。 我相信它将鼓励您探索有关此主题的更多信息。
• 在本系列文章中遇到的所有这些代码都是使用C ++ 20编译的（尽管在大多数情况下，我使用的是Modern C ++的功能，直到C ++ 17为止）。 因此，如果您无权访问最新的编译器，则可以使用https://wandbox.org/ ，它也已预装了boost库。

意图

不应强迫客户端依赖于不使用的接口。

• 接口隔离原则与单一职责原则密切相关。 真正的含义是，您应该始终以这样一种方式设计抽象，即使用公开方法的客户端不必获取整个饼图。 这给客户带来了实施他们实际上不需要的方法的负担。

动机：违反界面隔离原则

struct Document ;

struct IMachine {
    virtual void print (Document &doc)  = 0 ;
    virtual void fax (Document &doc)  = 0 ;
    virtual void scan (Document &doc)  = 0 ;
};

struct MultiFunctionPrinter : IMachine {      // OK
    void print (Document &doc) override  { }
    void fax (Document &doc) override  { }
    void scan (Document &doc) override  { }
};

struct Scanner : IMachine {                   // Not OK
    void print (Document &doc) override  { /* Blank */ }
    void fax (Document &doc) override  { /* Blank */ }
    void scan (Document &doc) override  {  
        // Do scanning ...
    }
};

• 如您所见，就MultiFunctionPrinter而言，可以实现由IMachine接口强制实施的print（），fax（）和scan（）方法。
• 但是，如果您只需要扫描仪或打印机，那么某些开发人员仍然继承IMachine并将空白的方法留空或抛出NotImplemented异常，无论哪种方式，您都做错了。

解决方案：C ++中的接口隔离原理示例

/* -------------------------------- Interfaces ----------------------------- */
struct IPrinter {
    virtual void print (Document &doc)  = 0 ;
};

struct IScanner {
    virtual void scan (Document &doc)  = 0 ;
};
/* ------------------------------------------------------------------------ */

struct Printer : IPrinter {
    void print (Document &doc) override ;
};

struct Scanner : IScanner {
    void scan (Document &doc) override ;
};

struct IMachine : IPrinter, IScanner { };

struct Machine : IMachine {
    IPrinter&   m_printer;
    IScanner&   m_scanner;

    Machine(IPrinter &p, IScanner &s) : printer{p}, scanner{s} { }

    void print (Document &doc) override  { printer.print(doc); }
    void scan (Document &doc) override  { scanner.scan(doc); }
};

• 这为客户提供了灵活性，使他们可以组合他们认为合适的抽象并提供不必要的实现。
• 如单一责任原则所述 。 您应避免具有多个职责的类和接口。 因为它们经常更改，使您的软件难以维护。 您应该尝试根据角色将接口拆分为多个接口 。

好处

=>更快的编译

• 如果您违反了ISP，即在界面中将方法塞入一起，
  当方法签名更改时，您需要重新编译所有派生类。 对于某些以慢速编译而闻名的C ++等已编译语言来说，这是一个重要方面。 虽然另一种解决方法是可以自我解释的。

=>可重用性

• 马丁还提到“胖接口”（带有其他无用方法的接口）会导致类之间的意外耦合。 因此，有经验的开发人员知道耦合是可重用性的祸根。

=>可维护性

• ISP更具通用性的好处是，通过避免不必要的依赖关系，系统可以

1. 更容易理解；
2. 测试起来更轻
3. 更快地改变。

• 同样，对于您的代码阅读者来说，从类声明行中了解您的类的工作将变得更加困难。 因此，如果开发人员仅看到一个可能继承了其他接口的上帝接口，则可能不会很明显。 比较

MyMachine : IMachine

至

MyMachine : IPrinter, IScanner, IFaxer

• 后者告诉您很多，前者使您充其量猜想。

使用C ++制作Craft.io接口隔离原理友好软件的标尺

• 当您开始通过确定参与您领域的主要角色来分解问题空间时，就会自然而然地遵循这一原则。 因此，这绝不是机械动作。
• 对自己的问题提出一个问题可能会帮助您纠正设计：

我需要这个接口上的所有方法吗？

结束语

即使大接口是一个潜在的问题，ISP也不关心接口的大小。 而是关于类是否使用它们所依赖的接口的方法。 因此，ISP在设计软件时提供的指导不力，但可以很好地指示其是否健康。

先前发布在 http://www.vishalchovatiya.com/interface-segregation-principle-in-cpp-solid-as-a-rock/

翻译自: https://hackernoon.com/solid-design-interface-segregation-principle-in-c-1a833wa8

solid测序列原理