Java 如何将高内聚性模型划分为不同的类

我有一个容器，里面住着8个人。现在我想让客户端打开/关闭不同的relais。到目前为止还不错

一种解决方案可以是：

container.tryTurnOn(1, true);
container.turnRandomOn(true); //turn relais random to on or not.

“1”表示“1”，而“真”表示尝试将其打开；false表示尝试关闭它。 如果我添加更多与relais本身相关的方法（改变颜色、自我破坏或其他一些创造性的东西），而不是容器，那么容器接口将会成长

因此，我认为一个好主意是为每一个rela设置一个自己的类，这样你就可以做类似的事情了

container.getRelais(1).tryTurnOn(true);
container.turnRandomOn(true); //this stay the same

现在我还有不同的规则： 仅允许将8继电器中的6设置为on。（容器的任务是确保这一点）

所以在这种情况下，我有几个问题：

container.tryTurnOn(1, true);
container.turnRandomOn(true); //turn relais random to on or not.

我从getRelais获得的Relais是贫血的，它只保存Relais状态，但功能在容器中，因为只有容器知道tryTurnOn（true）是否被允许（或者我应该将行为放入relais，通过容器访问其他relais？ 我遇到的第二个问题是循环依赖性：Relais向容器发送打开的愿望，因此它必须知道容器。容器还必须知道其子对象（relais），以检查relais的开启次数是否超过6次。 此外，我在这里不再有一个告诉不要问，因为容器向Relais询问它们的状态，并根据结果直接从Relais访问状态并进行更改

• 还有其他解决方案吗？
• 如何解决循环、封装、告诉、不问问题
• 我必须做的是，在这里得到一个好消息

问题的一个扩展：

container.tryTurnOn(1, true);
container.turnRandomOn(true); //turn relais random to on or not.

也许我想在这里添加一些规则：

container.tryTurnOn(1, true);
container.turnRandomOn(true); //turn relais random to on or not.

• 管理员可以打开7个relais，普通用户可以打开7个relais 只有6个继电器打开
• 如果在我的模型中，一个可能的太阳照得比80%还亮，那么只有3% 对于这两个（管理员和普通用户）都允许打开
• 如果太阳的亮度超过95%，控制器将关闭所有设备 雷莱斯

您将如何以面向对象的方式对其进行建模？ 问题域看起来非常内聚，因为所有人都必须知道所有的东西。 你会把行为放在哪里，你会把行为分成不同的部分吗？ 我现在不知道如何在OO风格中做到这一点，对我来说，似乎无论如何都会导致一些过程代码。但这就是为什么我要问^^

为了这个答案，我将谈论灯，因为我发现灯更容易形象化

---

断断续续地说，不要问，不断增长的界面 首先，台灯在这件事上没有发言权。更准确地说，我们可以让灯熄灭，但灯不知道是否可以打开

尝试在灯中建模on和off会导致灯询问其他灯的状态。这不是一个好的设计。即使您不相信tell-don-ask，这样的设计对于在没有全局锁的情况下保证线程安全来说也是一场噩梦

相反，让我们把灯是开还是关视为灯的外在因素。我们将有一组亮着的灯。打开一盏灯就是将它添加到收藏中。如果将其关闭，则会将其从集合中删除。集合可以有一个设置的最大容量，在那里你可以告诉不要问。您告诉集合添加灯，它知道是否可以以及如何添加。你不必问它有多少项，然后根据这些来决定

---

您可以决定其他属性是否需要是外部属性。例如，可以将颜色作为灯的属性。或者，您可以使用颜色服务，该服务保存从灯到颜色的字典/地图

我将只讨论开和关，您将了解哪些其他属性可能需要类似的处理

---

至关重要的是，容器的接口不必随着添加更多属性而增长。相反，您只需将它们添加到lamp类中，或者为它们添加一个新结构

---

管理 该集合不负责知道用户是否是管理员

相反，必须有一个请求对象，它将与用户会话相关联。边界必须将这个请求映射到一个控制器（这是路由器的责任），对于管理和非管理情况，我们将有不同的控制器

但是，打开的灯的集合是相同的。因此，我们将把这个类分成两部分：首先是一个没有约束的存储类，然后是一个负责检查的视图类，这是访问存储类的唯一方法。现在，控制器可以请求配置了不同最大容量的视图，这取决于我们是否正在处理来自管理员的请求

谁提出这些要求？当然是风景。必须有一些用户界面，用户-可能是管理员或不是管理员-将使用。此外，必须有一些会话管理系统，因为用户必须进行身份验证，否则……您将如何拥有角色

请注意，我在为不同的用例争论不同的控制器。没有一个大胖子控制一切

---

太阳 原来太阳是个演员。太阳将开始运作。当太阳的亮度改变时，我们可能不得不关灯

无论您如何对太阳建模，我们都需要一个太阳适配器来处理太阳亮度的变化。当亮度超过阈值（95%）时，适配器将调用控制器关闭所有灯

类似地，我们应该能够询问适配器最后的亮度值。我不确定控制器是否应该