设计原则之【迪米特法则】

设计原则是指导我们代码设计的一些经验总结,也就是“心法”;面向对象就是我们的“武器”;设计模式就是“招式”。

以心法为基础,以武器运用招式应对复杂的编程问题。

来吧,通过生活中一个小场景,一起系统学习这6大设计原则。

SOLID原则–SRP单一职责原则

SOLID原则–OCP开放封闭原则

SOLID法则–LSP里式替换原则

SOLID原则–ISP接口隔离原则

SOLID原则–DIP依赖反转原则

LOD迪米特法则

实习生表妹第一天去公司…

我:妹啊,第一天去公司感觉怎么样呢?

表妹:感觉同事们有些冷淡😔

我:咋啦?

表妹:我在办理入职的时候,和我对接的张同事突然有事走开了,我当时看另一位同事在聊微信,就麻烦他帮我办理,但是他却让我等张同事回来。

我:原来是这样子,首先,他不是你的直接对接人呀,其次,说不定他自己也有事情在处理呢。

这不很像我们软件开发中的“迪米特法则”嘛?


每个模块只应该了解那些与它关系密切的模块的有限知识。或者说,每个模块只和自己的朋友“说话”,不和陌生人“说话”。也叫“最少知识原则”。

从上面的描述中,我们可以看出,迪米特法则包含前后两个部分,如果我们把一个模块看作是一个人,那么要实现“一个人应该对其他人有最少的了解”,应该做到这两点:

1、只和直接的朋友交流;

2、减少对朋友的了解。

接下来就详细说说如何做到这两点。

首先,我们来看一下,什么叫“朋友”?

软件开发中的朋友:两个对象之间的耦合关系称之为“朋友”,通常有依赖、关联、聚合和组合等。而直接朋友则通常表现为关联、聚合和组合关系,即两个对象之间联系更为紧密,通常以成员变量,方法的参数和返回值的形式出现。

减少对朋友的了解

一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散就越大。

就如同前面的场景,表妹只知道自己的直接对接人是负责给新员工办理入职手续的,但是具体的操作,表妹是不知道的。

我们来看一下明星和粉丝互动的场景:

// 粉丝类
public class Fans {

    public void shakeHands(){
        System.out.println("与偶像握手");
    }
    public void sign(){
        System.out.println("偶像给我签名");
    }
    public void groupPhoto(){
        System.out.println("与偶像合影");
    }
    
    public void interaction(){
        shakeHands();
        sign();
        groupPhoto();
    }
}

// 偶像类
public class Star{
    private Fans f;
    
    ...
    
    public void interactWithFans(){
      // 现在偶像要和粉丝互动,正常来说,她只需要调用interaction()方法即可,
      // 但是,她发现Fans所有的方法都是公开的,该如何互动呢?可能:
        f.shakeHands();
        f.sign();
        f.groupPhoto();
        
        // 亦或是以下的操作 
        f.sign();
        f.groupPhoto();
        
        // 还可能是以下的操作
        f.interaction();
    }
}

你看,粉丝作为明星的朋友,公开了很多种互动方式,使得明星对粉丝的了解过多,这样明星得花很大精力去考虑以哪种方式和粉丝互动。那么,这里的f对象应该暴露哪些方法呢?很显然,对于明星Star来说,只需关注和粉丝的互动操作,而不关心具体是如何互动的,因此,只需要暴露interaction()方法。

那么,上述的代码应该修改为:

// 粉丝类
public class Fans {

    private void shakeHands(){
        System.out.println("与偶像握手");
    }
    private void sign(){
        System.out.println("偶像给我签名");
    }
    private void groupPhoto(){
        System.out.println("与偶像合影");
    }
    
    public void interaction(){
        shakeHands();
        sign();
        groupPhoto();
    }
}

// 偶像类
public class Star{
    private Fans f;
    
    ...
    
    public void interactWithFans(){
		// 这时候,偶像她只管与粉丝互动就可以了,不管具体是握手、签名还是合影。
        f.interaction();
    }
}

你看,这时明星和粉丝的互动就简单多了。

通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。

其实,明星由于全身心投入艺术,所以许多日常事务由经济人负责处理,如粉丝见面会,和媒体公司的业务洽谈等。这里的经纪人就是明星的直接朋友,粉丝和媒体公司是明星的间接朋友。

只和直接的朋友交流

现在,我们在刚才的场景中,加多一个经纪人类:

// 粉丝类
public class Fans {

    private void shakeHands(){
        System.out.println("与偶像握手");
    }
    private void sign(){
        System.out.println("偶像给我签名");
    }
    private void groupPhoto(){
        System.out.println("与偶像合影");
    }
    
    public void interaction(){
        shakeHands();
        sign();
        groupPhoto();
    }
}

// 经纪人类
public class Broker {
    private Fans f;       // 负责粉丝见面会
    private Company c;    // 负责商务洽谈
    ...
    
    // 开粉丝互动会
    public void openInteraction() {
        f.interaction();
    }
}

// 偶像类
public class Star{
    // 明星的经纪人
    private Broker b;
    
    ...
    
    // 粉丝互动会,由经纪人打理
    public void interactWithFans(){
    	b.openInteraction();
    }
}

你看,明星的直接朋友只有一个,也就是他的经纪人,无需了解粉丝和公司。这样做有一个好处,就是能够简化对象与对象之间的通信,进而减轻依赖,提供更高的灵活性,当然也可以提供一定的安全性。

总结

不该有直接依赖关系的类之间,不要有依赖;

有依赖关系的类之间,尽量只依赖必要的接口(也就是定义中的“有限知识”)。

好啦,不要为了应用设计原则而应用设计原则,我们在应用设计原则的时候,一定要具体问题具体分析。

参考

《大话设计模式》

《设计模式之禅》

https://www.jianshu.com/p/14589fb6978e

https://www.itheima.com/news/20210819/173818.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值