最近，我一直在阅读有关接口是抽象的假设错误概念的帖子。一个这样的帖子是http://blog.ploeh.dk/2010/12/02/InterfacesAreNotAbstractions.aspx
我有点困惑。如果我没有接口（接口/抽象类），那么我将如何注入我的依赖项并模拟它们？
另外，我听说人们谈论不使用只有一个实现者的接口。喜欢这个博客 - http://simpleprogrammer.com/2010/11/02/back-to-basics-what-is-an-interface/
现在这一切，是不是违反了原则——编程到接口而不是实现？
【问题讨论】：
标签： design-patterns interface abstraction
对接口而不是实现进行编程更多的是使用数据抽象和封装。
当我们在对接口进行编程方面说“接口”时。这种接口意味着类的面向外部的方法和属性。它不必是语言级别的界面。 （关键字界面。）
您应该努力确保您的代码不依赖于其他类的内部细节。
【讨论】：
我想说我不同意链接文章中的许多观点：
接口是合约。合约有两部分——方法签名（纯语法）和文档。
接口是抽象。我看不到 LSP 违规的示例。 IRectangle 的例子根本不是一个好例子。 Set extends Collection 也可以这样说，其中不允许添加重复项。如果您通过Collection 您可能会惊讶它不允许重复。使用Collection 接口，通过记录实现者可能会添加限制来解决此问题
泄漏的抽象是不可避免的。但这完全取决于设计师。顺便说一句，“接口是泄漏抽象”意味着它们是抽象。
这些家伙似乎错过了“接触”单元测试的机会。模拟实现是使用接口的一个很好的理由（尽管您也可以模拟具体的类）。
我们当前项目的一个很好的例子 - 最初我们只有一个 DAO 实现 - 一个从数据库中获取内容。但后来我们将一些操作切换到了专用的搜索引擎。我们添加了 DAO 的另一个实现，然后就可以了。因此，最初只有一个实现的接口得到了回报。
顺便说一句，最初 SortedSet 在 JDK 中只有一个实现 - TreeSet。现在它有两个。还有更多来自外部库。
话虽如此，您并不需要所有的接口。但这取决于具体情况。例如，我不使用辅助类的接口。文章的一个有效点是“对接口编程”不一定包含interface 关键字。类的“公共接口”（理论上）是其公共方法的集合。
【讨论】：
只要不过度，我相信你最好还是创建一个界面。
这是我经常遇到的一个用例，只有一个实现者（在我看来）完全没问题：你有一个 Swing 组件，假设它是一个CarComparisonResultsPanel，它允许用户查看两者之间的比较结果汽车。作为面板的用户，我宁愿拥有一个只有 getCarSimilarities() 和 getCarDifferences() 的 CarComparisonResult 接口，而不是实现这些方法以及其他许多方法的 JPanel 实现。
编辑：为了让我的“不要过度使用”这一点更清楚，这些是一些过度使用的示例：工厂接口、构建器、帮助器/实用程序类、不添加相关公共方法的 GUI 组件给他们的父母，...
【讨论】：
接口编程背后的原则不必只限于接口情况。当你设计你的界面时，你要问的一般问题是“我希望它在哪里被消费？由谁消费？目的是什么？”即使在创建实现类时也应该提出的问题。
可能是，在设计接口时，您会意识到您实际上并不需要将其设为接口，并且允许重载和继承就足以进行测试。正如第一篇文章所提到的，如果你总是以 1:1 的关系结束对象和接口，除了“我正在针对接口进行编程”之外没有其他目的，那么你只是把你的代码弄得一团糟。
但是，这并不意味着您不能继续设计该类，就好像您正在为其创建接口/基类一样，使用一组提供基本功能的通用方法/属性/字段，然后添加其他更具体的实现方法/属性/字段。 IMO 这样做仍然符合接口编程的原则。当出现明确而明确的需求时，它肯定也会为您提取接口/基类敞开大门。
【讨论】：