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 回答