对于“问，不说”的方法，需要说明

Question

我正在学习软件工程中的模式设计课程，在这里我试图理解与“耦合”和“凝聚力”相关的设计的好的和坏的方式。我无法理解下图中描述的概念。 图像中显示的代码示例对我来说是模棱两可的，所以我无法清楚地知道究竟是什么“问，不要告诉！”做法意味着！你能不能得到任何图像？如果是，请解释！

由于

Answer 1

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

我相信这个原则更为人所知the law of Demeter。我从来没有听说它被描述为“请不要告诉。”

Answer 2

我们不知道是什么，但这很好;没关系。重要的是你如何与它互动（它有什么方法）。为了便于说明，我们假设tum是X型。

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

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

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

Answer 3

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

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

在第二个你不告诉如何做到这一点。您反而要求 tum为您完成工作，但您没有详细说明如何执行此操作。这也意味着如果这些实现细节中的任何一个发生变化，您的代码仍然可以正常运行tum实施可以独立更改。

希望这有帮助。