"程序到接口"是C++项目中的常见设计原则吗？

Question

在过去的几天里,我读了很多关于"接口程序"和"控制反转"的内容.主要是在Java语言的上下文中.我的问题是它是否也是C++开发中的常见做法.有什么好处？有什么缺点？

是否值得申请小型项目(如15-20班)？

Answer 1

是的,这是相当普遍的,但不是你想象的形式.

在Java中,接口是形式化和显式的,对接口的编程意味着实现特定的接口interface.

在C++中,有时也是如此(尽管使用抽象基类而不是接口),但在C++中使用另一种常见方式是使用模板,其中接口是隐式的.

例如,标准库算法都使用迭代器"接口",除了在代码中没有定义过这样的接口.这是一个惯例,仅此而已.

需要有效的迭代器来公开某些功能,因此,任何公开此功能的类型都是迭代器.但它不必IIterator像在Java中那样实现某种假设的接口.

在用户代码中也是如此.您经常编写代码来接受模板参数,该模板参数可能是有效的.您通过使用类型隐式定义接口:您需要的任何内容都成为此隐式接口的一部分,类型必须满足该接口才能使用.

接口永远不会在代码中形式化,但您仍在使用它并对其进行编程.

Answer 2

您所说的原则通常适用于任何OO语言.这里的基本原则是"松耦合".依赖于另一个类(包含它的实例并在其上调用方法作为其自身工作的一部分)的类实际上仅依赖于依赖项提供的一组功能.如果类定义了,它依赖于一个具体的类的引用,然后你想替换另一个类,你不仅要开发新的类,但改变依赖类依赖于新的类型.这通常是不好的,因为如果你的类被许多其他类依赖,你必须在多个地方需要修改的代码,你需要测试所有涉及这些对象,以确保你没有破坏以前的工作功能的使用情况.

接口旨在消除这种情况,允许多个与祖先无关的类可以基于您知道类将实现的常见的强制方法集互换使用.如果您依赖于某个类,而不依赖于某个类,那么实现该接口的任何类都将满足该依赖关系.这允许你编写一个新类来替换旧类,而没有使用它的类知道差异.您需要修改的只是创建填充依赖项的类的具体实现的代码.

这提出了一个窘境; 当然,你的类Depender可以说,它需要一个IDoSomething代替DoerClass,但如果Depender知道如何创建一个DoerClass作为IDoSomething使用,你有没有什么上涨; 如果你想用BetterDoer替换DoerClass,你仍然必须改变Depender的代码.解决方案是赋予类向第三方(创建者)提供依赖关系实例的责任.为此选择的类取决于上下文.如果一个类自然同时具有Depender和DoerClass,那么将它们放在一起是显而易见的选择.当您有一个具有两个辅助依赖项的类时,通常就是这种情况,并且一个依赖项也需要另一个.其他时候您可以创建一个Factory,它可以为调用者提供特定对象的实例,

如果您有多个相互依赖的类或多个级别的依赖项,您可以考虑使用IoC框架.IoC容器属于工厂,因为存储库属于DAO; 他们知道如何让你的任何类的完全水化的情况下,需要一个或多个依赖,就像一个仓库可以从DB数据产生任何完全水化的域对象.它通过被告知应该用什么具体的类,以填补在一定情况下的依赖,并在需要时提供一个类,它将实例化类,提供了所需的依赖实例(和依赖的依赖)做到这一点.这可以让图案,其中A类依赖于B,这取决于C,但A不能了解C. IoC框架知道所有三个,并会实例化一个B,给它一个新的C,然后给B到一个新的一个.