design-patterns - 需要解释，用于“问，不说”的方法

Question

我正在学习软件工程中的模式设计课程，在这里我试图了解与“耦合”和“内聚”相关的设计的好坏。我无法理解下图中描述的概念。 图像中显示的代码示例对我来说是模棱两可的，所以我不太清楚到底是什么“问，不要说！” 接近的意思！你能从图像中得到什么吗？如果是，请解释！

谢谢

Answer 1

在第一个实现中，类的客户端代码与实现高度耦合，因为学生列表是用SortedList某种类型的 a 实现的这一事实被泄露。一旦从数百个其他地方使用该类，将其内部实现更改SortedList为其他东西就变得困难或不可能。第二种实现隐藏了实现细节，导致耦合更松。

我相信这个原则更好地称为得墨忒耳定律。我从未听说过它被描述为“问不说”。

Answer 2

我们不知道 tum 是什么，但这很好；没关系。重要的是你如何与它交互（它有什么方法）。出于说明目的，假设 tum 是 X 类型。

在不好的示例中，我们必须从 tum 获取 SortedList，然后开始使用 SortedList。这很糟糕，因为您将类型 X 与 SortedList 紧密耦合。将来，您可能不想使用 SortedList（或其子类）。如果您更改 X 使其使用数组、数据库、Web 服务器或其他任何东西，您将遇到许多潜在问题：

1. 您必须在添加学生的任何地方更改代码。对于一个小项目，可能只有几个地方。对于较大的项目，这可以在数百个地方使用，并且可能会令人头疼。
2. 如果您将类型 X 作为库公开给其他人使用，那么任何使用 X 的人都必须更新他们的代码。如果使用您的库的人必须在许多地方更新他们的代码，他们可能会非常沮丧。
3. 假设 SortedList 更改和方法被添加或删除（对于 SortedList 不太可能，但如果它是您创建的另一个类则可能）。您必须更新每个添加学生的地方，即使您只是更改学生的数据结构。

在更好的例子中， addStudentToLecture(...) 隐藏了它的实现细节。它可能正在使用 SortedList，也可能是其他东西。任何想要将学生添加到 tum 的人都不需要知道如何使用 SortedList，并且 addStudentToLecture(...) 的实现可以在不更改调用代码的情况下进行更改。

Answer 3

在第一个（或不好的）示例中，您告诉了要做什么。

您详细说明了如何将学生添加到讲座中。这有几件事是错误的。将tum其内部实现细节作为可变对象返回。客户端可能会弄乱它，可能会破坏tum类的不变量。也许这就是最大的缺陷。除此之外，您还取决于如何获取学生列表的详细信息以及如何添加学生的详细信息。如果这些细节中的任何一个发生变化，您的代码就会中断......

在第二个你不告诉如何去做。相反，您要求他们tum为您完成工作，但您没有详细说明如何做。这也意味着，如果这些实现细节中的任何一个发生变化，您的代码仍然可以；实现tum可以独立改变。

希望这可以帮助。