1

我非常了解接口的好处以及它如何帮助聚合相似类型对象的通用功能。但是我相信人们已经把这个“总是程序到一个界面”有点过分了。

a) 人们总是从定义一个接口开始，然后在一个类中实现它，即使该接口太具体而无法由任何其他类实现。- 我是唯一一个认为这没有用的人吗？

b) 强制所有“相关”接口派生为一个通用（无用）接口，因为它现在是“可扩展的”——什么？

c) 在两个或多个对象看似相关但由于其潜在差异而很难定义通用接口方法的情况下，您会怎么做？

例如，一个以方法命名的IConnection接口Connect()。（这就是大多数示例使接口变得平凡的方式）。问题是，实现 IConnection 接口的不同类型的类可能需要不同的数据来建立连接，有些可能需要用户名和密码，有些可能需要某种特殊的连接密钥，有些可能根本不需要。作为契约的Connect方法是完全有效的，因为每个类都需要某种方式来建立连接，但它们需要的数据是不同的。

在这种情况下是否需要接口？如果是，你如何定义Connect方法？如果不是，你如何证明你的具体类仍然是“可扩展的”？

对不起，长时间的咆哮，这已经困扰了我很长一段时间了。大多数人在阅读了著名的设计模式书后，会尝试在他们所做的每一件事中实现每一种可能的模式，而不会费心去弄清楚它是否有帮助。我相信当你面临一个问题时，这种模式应该发挥作用，而不仅仅是为了它。

4

1 回答 1

2

在您的 IConnection 示例中，您基本上是在描述一个抽象的 Connect() 方法，因为每个类都必须实现自己的版本。通常（总是？）抽象方法只能使用相同的参数来定义，因此 Connect(username, password) 和 Connect(key) 不能是来自接口的相同 Connect() 方法的实现。

现在，此时，您可以将其定义为 IConnection::Connect(SomeConnectionData) 并从 SomeConnectionData 类派生 UsernamePasswordConnectionData 和 KeyConnectionData 等，但所有这些都很难解释和实现，这是一个很好的线索接口和继承对这种情况没有帮助。

如果它使编程和使用变得更加困难，请不要这样做。如果某些东西因为变得太复杂而无法理解而变得“可扩展”，那么无论如何都不会扩展它。定义一堆类是完全可以的，每个类都有自己的 Connect() 方法，就像约定一样。

于 2013-06-20T02:54:39.120 回答