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