我非常了解接口的好处以及它如何帮助聚合类似对象的常见功能。但是我相信人们已经把这个“总是编程到接口”的程度太过分了。
a）人们开始时总是定义一个接口然后在一个类中实现它，即使该接口太具体而不能由任何其他类实现。 - 我是唯一一个认为这没有用处的人吗？
b）强制所有“相关”接口派生出一个普通（无用）接口，因为它现在是“可扩展的” - 什么？
c）在两个或多个对象看起来相关的场景中你做了什么，但由于其潜在的差异而很难定义通用的接口方法？
让我们举例说一个名为IConnection的接口，其中Connect()方法。 （这是大多数示例简化接口的方式）。问题是，实现IConnection接口的不同类型的类可能需要不同的数据来建立连接，有些可能需要用户名和密码，有些可能需要某种特殊的连接密钥，有些可能根本不需要任何东西。 Connect方法作为契约是完全有效的，因为每个类都需要某种方式来建立连接，但他们需要的数据是不同的。
在这种情况下是否需要接口？如果是，您如何定义Connect方法？如果没有，你如何证明你的具体课程仍然是“可扩展的”？
对不起长时间的咆哮，这已经困扰了我很长一段时间了。大多数人在阅读了着名的设计模式书之后，试着在他们所做的每件事情中实现所有可能的模式，而不必费心去弄清楚它是否有帮助。我相信当你遇到一个问题而不仅仅是为了它的问题时，这个模式应该发挥作用。
答案 0 :(得分：2)
在您的IConnection示例中，您基本上描述了一个抽象的Connect（）方法，因为每个类都必须实现自己的版本。通常（总是？）抽象方法只能使用相同的参数定义，因此Connect（用户名，密码）和Connect（key）不能从接口实现相同的Connect（）方法。
现在，在这一点上，您可以将它定义为IConnection :: Connect（SomeConnectionData）并从SomeConnectionData类派生UsernamePasswordConnectionData和KeyConnectionData等，但所有这些都很难解释并实现它的漂亮接口和继承没有帮助的情况很好的线索。
如果它编程并更难使用它，请不要这样做。如果通过变得太复杂而无法理解某些东西是“可扩展的”，那么无论如何都不会扩展它。定义一堆类是完全可以的，每个类都有自己的Connect（）方法，就像约定一样。