前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >软件架构设计原则之迪米特法则

软件架构设计原则之迪米特法则

原创
作者头像
Tom弹架构
修改2021-11-15 10:33:56
2900
修改2021-11-15 10:33:56
举报
文章被收录于专栏:Tom弹架构Tom弹架构

本文节选自《设计模式就该这样学》

迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类。

现在来设计一个权限系统,Boss需要查看目前发布到线上的课程数量。这时候,Boss要找到TeamLeader去进行统计,TeamLeader再把统计结果告诉Boss。接下来我们还是来看代码。

Course类的代码如下:

代码语言:txt
复制
public class Course {

}

TeamLeader类的代码如下:

代码语言:txt
复制
public class TeamLeader {

    public void checkNumberOfCourses(List<Course> courseList){

        System.out.println("目前已发布的课程数量是:"+courseList.size());

    }

}

Boss类的代码如下:

代码语言:txt
复制
public class Boss {

    public void commandCheckNumber(TeamLeader teamLeader){

    //模拟Boss一页一页往下翻页,TeamLeader实时统计

            List<Course> courseList = new ArrayList<Course>();

            for (int i= 0; i < 20 ;i ++){

                courseList.add(new Course());

            }

            teamLeader.checkNumberOfCourses(courseList);

        }

    }

测试代码如下:

代码语言:txt
复制
public static void main(String[] args) {

    Boss boss = new Boss();

    TeamLeader teamLeader = new TeamLeader();

    boss.commandCheckNumber(teamLeader);

}

写到这里,其实功能都已经实现,代码看上去也没什么问题。根据迪米特原则,Boss只想要结果,不需要跟Course直接交流。而TeamLeader统计需要引用Course对象。Boss和Course并不是朋友,从下面的类图就可以看出来。

图片1.png
图片1.png

下面对代码进行改造。

TeamLeader类的代码如下:

代码语言:txt
复制
public class TeamLeader {

    public void checkNumberOfCourses(){

        List<Course> courseList = new ArrayList<Course>();

        for(int i = 0 ;i < 20;i++){

            courseList.add(new Course());

        }

        System.out.println("目前已发布的课程数量是:"+courseList.size());

    }

}

Boss类的代码如下:

代码语言:txt
复制
public class Boss {

    public void commandCheckNumber(TeamLeader teamLeader){

        teamLeader.checkNumberOfCourses();

    }

}

再来看下面的类图,Course和Boss已经没有关联了。

图片2.png
图片2.png

学习软件设计原则,千万不能形成强迫症。碰到业务复杂的场景,我们需要随机应变。

关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。

【推荐】Tom弹架构:30个设计模式真实案例(附源码),挑战年薪60W不是梦

本文为“Tom弹架构”原创,转载请注明出处。技术在于分享,我分享我快乐!如果本文对您有帮助,欢迎关注和点赞;如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货!

其他设计原则

Tom弹架构:开闭原则(Open-Closed Principle,OCP)

Tom弹架构:依赖倒置原则(Dependence Inversion Principle,DIP)

Tom弹架构:单一职责原则(Simple Responsibility Pinciple,SRP)

Tom弹架构:接口隔离原则(Interface Segregation Principle, ISP)

Tom弹架构:里氏替换原则(Liskov Substitution Principle,LSP)

Tom弹架构:合成复用原则(Composite/Aggregate Reuse Principle,CARP)

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档