Oop 深层阶级构成与德米特定律

Oop 深层阶级构成与德米特定律,oop,design-patterns,composition,loose-coupling,law-of-demeter,Oop,Design Patterns,Composition,Loose Coupling,Law Of Demeter,晚上好。我很难找到适合深层构图的设计模式。让我举个例子 假设我们有一类类型的公司,有许多类型的子公司,有许多类型的部门,在类型中包含许多类型的单位,反过来又包含许多类型的员工 现在,假设用例是统计每个公司的员工数量。我可以循环每一个公司,再循环每一个子公司,依此类推,这样会产生一个嵌套的循环,4层深。另外,通过引用下面几个级别的类链,我将打破德米特定律,这是一个紧密耦合的东西,在我修改我的类链的那一刻就会打破 我可以做的另一件事是添加成吨(好的,也许不是成吨,但有一些)的快捷方式引用。例如,一家

晚上好。我很难找到适合深层构图的设计模式。让我举个例子

假设我们有一类类型的公司,有许多类型的子公司,有许多类型的部门,在类型中包含许多类型的单位,反过来又包含许多类型的员工

现在,假设用例是统计每个公司的员工数量。我可以循环每一个公司,再循环每一个子公司,依此类推,这样会产生一个嵌套的循环,4层深。另外,通过引用下面几个级别的类链,我将打破德米特定律,这是一个紧密耦合的东西,在我修改我的类链的那一刻就会打破

我可以做的另一件事是添加成吨(好的,也许不是成吨,但有一些)的快捷方式引用。例如,一家公司本身也可以包含一份员工名单,这样就不必在整个链条中对员工进行计数。这样,类之间的耦合就不那么紧密了(但它们是吗?),现在的问题是如何使公司和部门的员工列表保持同步。我想我可以使用观察者模式来保持它们的更新,但我真的觉得这个想法有严重的问题,或者至少,我没有真正使用最好的解决方案

因为我很确定这是一个非常常见的领域,有人能告诉我一个合适的设计模式吗


谢谢。

我不太明白第二个问题,但我正在回答第一个问题

正如德米特法所规定的,每个实体都应该拥有最少的 对其他单位的了解

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

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()
方法,从而进入任意深度。这里没有必要破坏封装或使用观察者模式

应用您在评论中指出的原则,并将计算包含员工的类的实际员工的责任委派给您

Department - > uses count method on subsidiaries to add their count
Subsidiaries - > uses Units to count
Unit - > Uses employees to count
假设您想通过链接或按钮向客户发送电子邮件。您可以像customer.getSomeSpecialContactinfo(addressType).sendEmail()或customer.sendEmail()那样编写它,然后(在客户内部)调用getSomeSpecialContactinfo(“主”).sendEmail()


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

这就是我提到的快捷方式的建议。但是,如果我要实现countEmployees(),我需要,比如说,一组雇员,对吗?基本上必须是Unit类包含的同一个Employee数组。我需要保持它们的同步,可能是一个观察者模式。这也是你的建议吗?不,谁的财产是雇员?这是一个单位吗?然后,您需要为子公司创建快捷方式,这将反过来调用包含员工的单位的快捷方式。您不需要从unit类中提取employees。因此,顺序类链中的每个方法都将包含一个countEmployees()方法,该方法将调用下一个类的counteEmployees()方法。我想这是有道理的,因为我可以计算我想要的任何级别的员工。我喜欢这种方法,谢谢你的意见。顺便问一下,你怎么称呼这个原则?是吗?我同意这种方法。公司可以通过要求每个子公司进行计数并将这些结果加总来进行计数,以此类推。但是这样的话,如果你在细节上有特殊情况,比如一个子公司的董事超过两个单位,该子公司可以负责确保他在其计数方法中准确计数一次。是的,这就是德米特法规定的,你不必解雇员工。同样要记住责任原则,员工应该是班级中有责任拥有他们的一员:)