2

晚上。对于某些深度组合的情况，我很难找到合适的设计模式。让我举一个例子。

假设我们有一个 Corporation 类型的类，它有许多 Subsidiary 类型的类，它有许多 Department 类型的类，这些类在类型中包含许多 Unit 类型的类，而 Unit 类型又包含许多 Employee 类型的类。

现在，假设用例是计算每个公司的员工人数。我可以遍历每个公司，为每个子公司再次循环，依此类推，这样会导致嵌套循环，深度为 4 级。另外，如果我在下面几个级别引用我的职业链，我会违反得墨忒耳法则，这会在我修改我的链条的那一刻被打破。

我可以做的另一件事是添加大量的快捷方式引用（好吧也许不是很多，但有一些）。例如，一家公司本身也可以包含一个员工列表，从而无需遍历整个链条来计算他们。这样一来，类的耦合度就降低了（但它们是吗？），现在的问题变成了如何使 Corporation 和 Unit 的 Employee 列表保持同步。我想我可以使用观察者模式来让它们保持更新，但我真的觉得这个想法有什么可怕的错误，或者至少，我并没有真正使用那里最好的解决方案。

因为我很确定这是一个非常常见的领域，有谁能给我指出一个合适的设计模式吗？

谢谢。

4

2 回答 2

1

我没有完全得到第二个问题，但我正在回答第一个问题。

正如得墨忒耳定律所说，每个实体都应该对其他单位有最少的了解

所以在你的设计中使用这个原则

class Corporation{

    //All the stuff about corporation

    //Don't ask for what's inside corporation
    public int countEmployees(){
        //will apply the logic needed to calculate
    }

}

使用得墨忒耳法则更好的客户端代码：

corporationInstance.countEmployees(); //let the corporation handle how to count and not expose inner details

没有得墨忒耳法则

corporationInstace.getSubsidiaries().getSomethingElse()..... //exposing the inner details of class which creates a chain that is bad.

更新：

使用上述解决方案，您可以根据需要在内部和内部创建countEmployees()方法，从而进入任意多的深度。在这里打破封装或使用观察者模式是没有意义的。SubsidiariesUnit

应用您自己在评论中指出的告诉不要问原则，并委派计算包含员工的类的实际员工的责任。

Department - > uses count method on subsidiaries to add their count
Subsidiaries - > uses Units to count
Unit - > Uses employees to count
于 2013-08-30T19:42:00.790 回答
0

假设您想通过链接或按钮向客户发送电子邮件。您可以将其编写为 customer.getSomeParticularContactInfo(addressType).sendEmail() 或 customer.sendEmail()，然后（在 Customer 内部）调用 getSomeParticularContactInfo("primary").sendEmail()。

你走错路了。这打破了单一责任，我的意思是，客户对象不需要知道如何发送电子邮件，客户对象只负责如何提供属于客户的电子邮件地址。因此，对于此功能，您需要创建另一个接口，例如 Notifier 和实现 Notifier 的 EmailNotifier。此后，您将致电 EmailNotifier.notify(customer)

于 2015-07-05T16:34:02.560 回答