精华内容
下载资源
问答
  • 2018-12-25 18:59:59

    原则概述

    1. 单一职责原则(Single Responsibility Principle)

    每一个类应该专注于做一件事情。
    

    2. 开闭原则(Open Close Principle)

    面向扩展开放,面向修改关闭。
    

    3. 里氏替换原则(Liskov Substitution Principle)

    超类存在的地方,子类是可以替换的。
    

    4. 接口隔离原则(Interface Segregation Principle)

    应当为客户端提供尽可能小的单独的接口,而不是提供大的总的接口。
    

    5. 依赖倒置原则(Dependence Inversion Principle)

    实现尽量依赖抽象,不依赖具体实现。
    

    6. 迪米特法则(Law Of Demeter)

    又叫最少知识原则,一个软件实体应当尽可能少的与其他实体发生相互作用。
    

    7. 组合/聚合复用原则(Composite/Aggregate Reuse Principle CARP)

    尽量使用合成/聚合达到复用,尽量少用继承。原则: 一个类中有另一个类的对象。
    

    原则详解

    1. 单一职责原则(Single Responsibility Principle)

    因为:

    可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;提高类的可读性,提高系统的可维护性;变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则。

    所以:

    从大局上看Android中的Paint和Canvas等类都遵守单一职责原则,Paint和Canvas各司其职。

    示例:

    新建一个Rectangle类,该类包含两个方法,一个用于把矩形绘制在屏幕上,一个方法用于计算矩形的面积。

    Rectangle类违反了SRP原则。Rectangle类具有两个职责,如果其中一个改变,会影响到两个应用程序的变化。

    一个好的设计是把两个职责分离出来放在两个不同的类中,这样任何一个变化都不会影响到其他的应用程序。

    2. 开闭原则(Open Close Principle)

    因为:

    开放封闭原则主要体现在对扩展开放、对修改封闭,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。软件需求总是变化的,世界上没有一个软件的是不变的,因此对软件设计人员来说,必须在不需要对原有系统进行修改的情况下,实现灵活的系统扩展。

    所以:

    可以通过Template Method模式和Strategy模式进行重构,实现对修改封闭,对扩展开放的设计思路。
    封装变化,是实现开放封闭原则的重要手段,对于经常发生变化的状态,一般将其封装为一个抽象,拒绝滥用抽象,只将经常变化的部分进行抽象。

    示例:

    public boolean sendByEmail(String addr, String title, String content) {
    }public boolean sendBySMS(String addr, String content) {
    }
    // 在其它地方调用上述方法发送信息
    sendByEmail(addr, title, content);
    sendBySMS(addr, content);
    

    如果现在又多了一种发送信息的方式,比如可以通过QQ发送信息,那么不仅需要增加一个方法sendByQQ(),还需要在调用它的地方进行修改,违反了OCP原则,更好的方式是

    抽象出一个Send接口,里面有个send()方法,然后让SendByEmail和SendBySMS去实现它既可。这样即使多了一个通过QQ发送的请求,那么只要再添加一个SendByQQ实现类实现Send接口既可。这样就不需要修改已有的接口定义和已实现类,很好的遵循了OCP原则。

    3. 里氏替换原则(Liskov Substitution Principle)

    因为:

    里氏替换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。里氏替换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。

    所以:

    使用里氏替换原则时需要注意,子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。

    从大局看Java的多态就属于这个原则。

    4. 接口隔离原则(Interface Segregation Principle)

    不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。

    客户模块不应该依赖大的接口,应该裁减为小的接口给客户模块使用,以减少依赖性。如Java中一个类实现多个接口,不同的接口给不用的客户模块使用,而不是提供给客户模块一个大的接口。

    示例:

    public interface Animal {
    	public void eat(); // 吃
    	public void sleep(); // 睡
    	public void crawl(); // 爬
    	public void run(); // 跑
    }
    
    public class Snake implements Animal {
    	public void eat() {
    	}
    	public void sleep() {
    	}
    	public void crawl() {
    	}
    	public void run() {
    	}
    }
    
    public class Rabit implements Animal {
    	public void eat() {
    	}
    	public void sleep() {
    	}
    	public void crawl() {
    	}
    	public void run() {
    	}
    }
    

    上面的例子,Snake并没有run的行为而Rabbit并没有crawl的行为,而这里它们却必须实现这样不必要的方法,更好的方法是crawl()和run()单独作为一个接口,这需要根据实际情况进行调整,反正不要把什么功能都放在一个大的接口里,而这些功能并不是每个继承该接口的类都所必须的。

    5. 依赖倒置原则(Dependence Inversion Principle)

    因为:

    具体依赖抽象,上层依赖下层。假设B是较A低的模块,但B需要使用到A的功能,这个时候,B不应当直接使用A中的具体类;而应当由B定义一抽象接口,并由A来实现这个抽象接口,B只使用这个抽象接口;这样就达到了依赖倒置的目的,B也解除了对A的依赖,反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块,假如B也直接依赖A的实现,那么就可能造成循环依赖。

    所以:

    采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,减少并行开发引起的风险,提高代码的可读性和可维护性。

    从大局看Java的多态就属于这个原则。

    6. 迪米特法则(Law Of Demeter)

    因为:

    类与类之间的关系越密切,耦合度也就越来越大,只有尽量降低类与类之间的耦合才符合设计模式;对于被依赖的类来说,无论逻辑多复杂都要尽量封装在类的内部;每个对象都会与其他对象有耦合关系,我们称出现成员变量、方法参数、方法返回值中的类为直接的耦合依赖,而出现在局部变量中的类则不是直接耦合依赖,也就是说,不是直接耦合依赖的类最好不要作为局部变量的形式出现在类的内部。

    所以:

    一个对象对另一个对象知道的越少越好,即一个软件实体应当尽可能少的与其他实体发生相互作用,在一个类里能少用多少其他类就少用多少,尤其是局部变量的依赖类,能省略尽量省略。同时如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话,可以通过第三者转发这个调用。

    从大局来说Android App开发中的多Fragment与依赖的Activity间交互通信遵守了这一法则。

    7. 组合/聚合复用原则(Composite/Aggregate Reuse Principle CARP)

    因为:

    其实整个设计模式就是在讲如何类与类之间的组合/聚合。在一个新的对象里面通过关联关系(包括组合关系和聚合关系)使用一些已有的对象,使之成为新对象的一部分,新对象通过委派调用已有对象的方法达到复用其已有功能的目的。也就是,要尽量使用类的合成复用,尽量不要使用继承。

    如果为了复用,便使用继承的方式将两个不相干的类联系在一起,违反里氏代换原则,哪是生搬硬套,忽略了继承了缺点。继承复用破坏数据封装性,将基类的实现细节全部暴露给了派生类,基类的内部细节常常对派生类是透明的,白箱复用;虽然简单,但不安全,不能在程序的运行过程中随便改变;基类的实现发生了改变,派生类的实现也不得不改变;从基类继承而来的派生类是静态的,不可能在运行时间内发生改变,因此没有足够的灵活性。

    所以:

    组合/聚合复用原则可以使系统更加灵活,类与类之间的耦合度降低,一个类的变化对其他类造成的影响相对较少,因此一般首选使用组合/聚合来实现复用;其次才考虑继承,在使用继承时,需要严格遵循里氏代换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度,因此需要慎重使用继承复用。

    参考文章:
    https://www.cnblogs.com/sunflower627/p/4718702.html
    https://www.imooc.com/article/51098#

    更多相关内容
  • 算法将基于关键点的特征匹配问题转化为求解平衡指派的最优化问题,进而依据整体匹配最优的原则实现特征的联合匹配。跟踪过程为:首先分别提取目标模板和当前搜索区域的局部关键点并进行特征描述;然后依据联合匹配...
  • 通过27根剖分T型钢压杆试验,借助通用有限元软件对单轴对称钢压杆的整体-9局部相关屈曲做了计算分析,分析时考虑了残余应力、几何和材料...按照等稳定原则设计,薄壁构件对初始缺陷较为敏感,整体和局部相关作用明显。
  • 为了对煤巷围岩稳定性进行科学分类,统计24篇分类文献,建立SPSS分类指标数据库,进行频数分析,研究指标的频数和分布特征,得出重点分类指标,同时考虑指标选取原则和山西焦煤实际情况,确定了11个分类指标。联合应用遗传...
  • 在总结国内外导流隧洞封堵设计一般原则的基础上,对堵头稳定性校核的各种计算理论进行了探讨。结合工程实例,介绍了使用有限元方法计算堵头稳定性的过程和步骤,着重分析了围岩变形模量、堵头体型对混凝土与围岩接触...
  • 一个懂设计原则的程序猿,写出来的代码可扩展性就是强,后续的人看代码如沐春风。相反,如果代码写的跟流水账似的,完全一根筋平铺下来,后续无论换谁接手维护都要骂娘。 做软件开发多年,CRUD仿佛已经形成一种...

    知识分享,以技会友。大家好,我是Tom哥。阅读本文大约需要 15 分钟。

     

    闲言碎语:

     

    一个懂设计原则的程序猿,写出来的代码可扩展性就是强,后续的人看代码如沐春风。相反,如果代码写的跟流水账似的,完全一根筋平铺下来,后续无论换谁接手维护都要骂娘。

     

    做软件开发多年,CRUD仿佛已经形成一种惯性,深入骨髓,按照常规的结构拆分:表现层业务逻辑层数据持久层,一个功能只需要个把小时代码就撸完了。

    再结合CTRL+CCTRL+V 绝世秘籍,一个个功能点便如同雨后春笋般被快速克隆实现。

    是不是有种雄霸天下的感觉,管他什么业务场景,大爷我一梭到底,天下无敌!!!

     

    图片

    可现实真的是这样?

    答案不言而喻!!!

    初入软件行业,很多人都会经历这个阶段。时间久了,很多人便产生困惑,能力并没有随着工作年限得到同比提升,焦虑失眠,如何改变现状?

    悟性高的人,很快能从一堆乱麻中找到线索,并不断的提升自己的能力。

    什么能力?

    当然是软件架构能力,一名优秀的软件架构师,要具备复杂的业务系统的吞吐设计能力抽象能力扩展能力稳定性

    如何培养这样能力?

     

    图片

    我将常用的软件架构原则,做了汇总,目录如下:

     

    图片

     

    当然这些原则有些是相互辅助,有些是相互矛盾的。实际项目开发中,要根据具体业务场景,灵活应对。千万不能教条主义,生搬硬套

     

     

    单一职责

     

    我们在编码的时候,为了省事,总是喜欢在一个类中添加各种各样的功能。未来业务迭代时,再不断的修改这个类,导致后续的维护成本很高,耦合性大。牵一发而动全身。

    为了解决这个问题,我们在架构设计时通常会考虑单一职责

    定义:

    单一职责(SRP:Single Responsibility Principle),面向对象五个基本原则(SOLID)之一。每个功能只有一个职责,这样发生变化的原因也会只有一个。通过缩小职责范围,尽量减少错误的发生。

    单一职责原则和一个类只干一件事之间,最大的差别就是,将变化纳入了考量。

    代码要求:

    一个接口、类、方法只负责一项职责,简单清晰。

    优点:

    降低了类的复杂度,提高类的可读性、可维护性。进而提升系统的可维护性,降低变更引起的风险

    示例:

    有一个用户服务接口UserService,提供了用户注册、登录、查询个人信息的方法,主要还是围绕用户相关的服务,看似合理。

    public interface UserService{
        // 注册接口
        Object register(Object param);
        // 登录接口
        Object login(Object param);
        // 查询用户信息
        Object queryUserInfoById(Long uid);
    } 
    

    过了几天,业务方提了一个需求,用户可以参加项目。简单的做法是在UserService类中增加一个joinProject()方法

    又过了几天,业务方又提了一个需求,统计一个用户参加过多少个项目,我们是不是又在UserService类中增加一个countProject()方法。

    这样导致的后果是,UserService类的职责越来越重,类会不断膨胀,内部的实现会越来越复杂。既要负责用户相关还有负责项目相关,后续任何一块业务变动,都会导致这个类的修改。

    两类不同的需求,都改到同一个类。正确做法是,把不同的需求引起的变动拆分开,单独构建一个ProjectService类,专门负责项目相关的功能

    public interface ProjectService{
        // 加入一个项目
        void addProject (Object param);
        // 统计一个用户参加过多少个项目
        void countProject(Object param);
    }
    

    这样带来的好处是,用户相关的需求只要改动UserService。如果是项目管理的需求,只需要改动ProjectService。二者各自变动的理由就少了很多。

     

    开闭原则

     

    开闭原则(OCP:Open-Closed Principle),主要指一个类、方法、模块 等 对扩展开放,对修改关闭。简单来讲,一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

    个人感觉,开闭原则在所有的原则中最重要,像我们耳熟能详的23种设计模式,大部分都是遵循开闭原则,来解决代码的扩展性问题。

     

    实现思路:

    采用抽象构建框架主体,用实现扩展细节。不同的业务采用不用的子类,尽量避免修改已有代码。

    优点:

    • 可复用性好。在软件完成以后,仍然可以对软件进行扩展,加入新的功能,非常灵活。因此,这个软件系统就可以通过不断地增加新的组件,来满足不断变化的需求。

    • 可维护性好。它的底层抽象相对固定,不用担心软件系统中原有组件的稳定性,这就使变化中的软件系统有一定的稳定性和延续性。

    示例:

    比如有这样一个业务场景,我们的电商支付平台,需要接入一些支付渠道,项目刚启动时由于时间紧张,我们只接入微信支付,那么我们的代码这样写:

    class WeixinPay {
        public Object pay(Object requestParam) {
            // 请求微信完成支付
            // 省略。。。。
            return new Object();
        }
    }
    

    随着业务扩展,后期开始逐步接入一些其他的支付渠道,比如支付宝云闪付红包支付零钱包支付积分支付等,要如何迭代?

    class PayGateway {
        public Object pay(Object requestParam) {
    
            if(微信支付){
                // 请求微信完成支付
                // 省略。。。。
            }esle if(支付宝){
                // 请求支付宝完成支付
                // 省略。。。。
            }esle if(云闪付){
                // 请求云闪付完成支付
                // 省略。。。。
            }
             // 其他,不同渠道的个性化参数的抽取,转换,适配
             // 可能有些渠道一次支付需要多次接口请求,获取一些前置准备参数
             // 省略。。。。
            return new Object();
        }
    }
    

    所有的业务逻辑都集中到一个方法中,每一个支付渠道本身的业务逻辑又相当复杂,随着更多支付渠道的接入,pay方法中的代码逻辑会越来越重,维护性只会越来越差。每一次改动都要回归测试所有的支付渠道,劳民伤财。那么有没有什么好的设计原则,来解决这个问题。我们可以尝试按开闭原则重新编排代码

    首先定义一个支付渠道的抽象接口类,把所有的支付渠道的骨架抽象出来。设计一系列的插入点,并对若干插入点流程关联。

    关于插入点,用过OpenResty的同学都知道,通过set_by_lua、rewrite_by_lua、body_filter_by_lua 等不同阶段来处理请求在对应阶段的逻辑,有效的避免各种衍生问题。

    abstract class AbstractPayChannel {
        public Object pay(Object requestParam) {
            // 抽象方法
        }
    }
    

    逐个实现不同支付渠道的子类,如:AliayPayChannelWeixinPayChannel,每个渠道都是独立的,后期如果做渠道升级维护,只需修改对应的子类即可,降低修改代码的影响面。

    class AliayPayChannel extends  AbstractPayChannel{
        public Object pay(Object requestParam) {
            // 根据请求参数,如果选择支付宝支付,处理后续流程
            // 支付宝处理
        }
    }
    class WeixinPayChannel extends  AbstractPayChannel{
        public Object pay(Object requestParam) {
            // 根据请求参数,如果选择微信支付,处理后续流程
            // 微信处理
        }
    }
    

    总调度入口,遍历所有的支付渠道,根据requestParam里的参数,判断当前渠道是否处理本次请求。

    当然,也有可能采用组合支付的方式,比如,红包支付+微信支付,可以通过上下文参数,传递一些中间态的数据。

    class PayGateway {
    
        List<AbstractPayChannel> payChannelList;
    
        public Object pay(Object requestParam) {
            for(AbstractPayChannel channel:payChannelList){
                channel.pay(requestParam);
            }
        }
    }
    

     

    里氏替换

     

    里氏替换原则(LSP:Liskov Substitution Principle):所有引用基类的地方必须能透明地使用其子类的对象

    简单来讲,子类可以扩展父类的功能,但不能改变父类原有的功能(如:不能改变父类的入参,返回),跟面向对象编程的多态性类似。

    多态是面向对象编程语言的一种语法,是一种代码实现的思路。而里氏替换是一种设计原则,是用来指导继承关系中子类如何设计,子类的设计要保证在替换父类的时候,不改变原有程序的逻辑以及不破坏原有程序的正确性。

    实现思路:

    • 子类可以实现父类的抽象方法

    • 子类中可以增加自己特有的方法。

    • 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。

    • 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

     

    接口隔离

     

    接口隔离原则(ISP:Interface Segregation Principle)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含调用方感兴趣的方法,而不应该强迫调用方依赖它不需要的接口。

    实现思路:

    • 接口尽量小,但是要有限度。一个接口只服务于一个子模块或业务逻辑。

    • 为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。

    • 结合业务,因地制宜。每个项目或产品都有特定的环境因素,环境不同,接口拆分的标准就不同,需要我们有较强的业务 sense

    • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

    示例:

    用户中心封装了一套UserService接口,给上层调用(业务端以及管理后台)提供用户基础服务。

    public interface UserService{
        // 注册接口
        Object register(Object param);
        // 登录接口
        Object login(Object param);
        // 查询用户信息
        Object queryUserInfoById(Long uid);
    }
    

    但随着业务衍化,我们需要提供一个删除用户功能,常规的做法是直接在UserService接口中增加一个deleteById方法,比较简单。

    但这样会带来一个安全隐患,如果该方法被普通权限的业务方误调用,容易导致误删用户,引发灾难。

    如何避免这个问题,我们可以采用接口隔离的原则

    定义一个全新的接口服务,并提供deleteById方法,BopsUserService接口只提供给Bops管理后台系统使用。

    public interface BopsUserService{
        // 删除用户
        Object deleteById(Long uid);
    }
    

    总结一下,在设计微服务接口时,如果其中一些方法只限于部分调用者使用,我们可以将其拆分出来,独立封装,而不是强迫所有的调用方都能看到它。

     

    依赖倒置

     

    软件设计中的细节具有多变性,但是抽象相对稳定,为了利用好这个特性,我们引入了依赖倒置原则。

    依赖倒置原则(DIP:Dependence Inversion Principle):高层模块不应直接依赖低层模块,二者应依赖于抽象;抽象不应该依赖实现细节;而实现细节应该依赖于抽象。

    依赖倒置原则的主要思想是要面向接口编程,不要面向具体实现编程。

    示例:

    定义一个消息发送接口MessageSender,具体的实例Bean注入到Handler,触发完成消息的发送。

    interface MessageSender {
      void send(Message message);
    }
    
    class Handler {
    
      @Resource
      private MessageSender sender;
      
      void execute() {
         sender.send(message);
      }
    }
    

    假如消息的发送采用Kafka消息中间件,我们需要定义一个KafkaMessageSender实现类来实现具体的发送逻辑。

    class KafkaMessageSender implements MessageSender {
      private KafkaProducer producer;
      
      public void send(final Message message) {
         producer.send(new KafkaRecord<>("topic", message));
      }
    }
    

    这样实现的好处,将高层模块与低层实现解耦开来。假如,后期公司升级消息中间件框架,采用Pulsar,我们只需要定义一个PulsarMessageSender类即可,借助Spring容器的@Resource会自动将其Bean实例依赖注入。

    优点:

    • 降低类间的耦合性

    • 提高系统的稳定性

    • 降低并行开发引起的风险

    • 提高代码的可读性和可维护性

    最后,要玩溜依赖倒置原则,必须要熟悉控制反转依赖注入,如果你是java后端,这两个词语你一定不陌生,Spring框架核心设计就是依赖这两个原则。

     

    简单原则

     

    复杂系统的终极架构思路就是化繁为简,此简单非彼简单,简单意味着灵活性的无限扩展,接下来我们来了解下这个简单原则。

    简单原则(KISS:Keep It Simple and Stupid)。翻译过来,保持简单,保持愚蠢。

    我们深入剖析下这个 “简单”:

    1、简单不等于简单设计或简单编程。软件开发中,为了赶时间进度,很多技术方案简化甚至没有技术方案,认为后面再找时间重构,编码时,风格随意,追求本次项目快速落地,导致欠下一大堆技术债。长此以往,项目维护成本越来越高。

    保持简单并不是只能做简单设计或简单编程,而是做设计或编程时要努力以最终产出简单为目标,过程可能非常复杂也没关系。

    2、简单不等于数量少。这两者没有必然联系,代码行少或者引入不熟悉的开源框架,看似简单,但可能引入更复杂的问题。

    如何写出“简单”的代码?

    • 不要长期进行打补丁式的编码

    • 不要炫耀编程技巧

    • 不要简单编程

    • 不要过早优化

    • 要定期做 Code Review

    • 要选择合适的编码规范

    • 要适时重构

    • 要有目标地逐渐优化

     

    最少原则

     

    最少原则也称迪米特法则(LoD:Law of Demeter)。迪米特法则定义只与你的直接朋友交谈,不跟“陌生人”说话。

    如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

    核心思路:

    • 一个类只应该与它直接相关的类通信

    • 每一个类应该知道自己需要的最少知识

    示例:

    现在的软件采用分层架构,比如常见的Web --> Service --> Dao 三层结构。如果中间的Service层没有什么业务逻辑,但是按照迪米特法则保持层之间的密切联系,也要定义一个类,纯粹用于Web层Dao层之间的调用转发。

    这样传递效率势必低下,而且存在大量代码冗余。面对此问题,我们需灵活应对,早期可以允许Web层直接调用Dao。后面随着业务复杂度的提高,我们可以慢慢将Controller中的重业务逻辑收拢沉淀到Service层中。随着架构的衍化,清晰的分层开始慢慢沉淀下来。

    写在最后,迪米特法则关心局部简化,这样很容易忽视整体的简化。

     

    表达原则

     

    代码的可维护性也是考验工程师能力的一个重要标准。试问一个人写的代码,每次code review时都是一堆问题,你会觉得他靠谱吗?

    这时候我们就需要引入一个表达原则

    表达原则(Program Intently and Expressively,简称 PIE),起源于敏捷编程,是指编程时应该有清晰的编程意图,并通过代码明确地表达出来。

    表达原则的核心思想:代码即文档,通过代码清晰地表达我们的真实意图。

    那么如何提高代码的可读性?

    1、优化代码表现形式

    无论是变量名、类名还是方法名,要命名合理,要能清晰准确的表达含义。再配合一定的中文注释,基本不用看设计文档就能快速的熟悉项目代码,理解原作者的意图。

    2、改进控制流和逻辑

    控制嵌套代码的深度,比如if else的深度最好不要超多三层。外层最好提前做否定式判断,提前终止操作或返回。这样的代码逻辑清晰。下面示例便是正确的处理:

    public List<User> getStudents(int uid) {
        List<User> result = new ArrayList<>();
        User user = getUserByUid(uid);
        if (null == user) {
            System.out.println("获取员工信息失败");
            return result;
        }
        
        Manager manager = user.getManager();
        if (null == manager) {
            System.out.println("获取领导信息失败");
            return result;
        }
    
        List<User> users = manager.getUsers();
        if (null == users || users.size() == 0) {
            System.out.println("获取员工列表失败");
            return result;
        }
    
        for (User user1 : users) {
            if (user1.getAge() > 35 && "MALE".equals(user1.getSex())) {
                result.add(user1);
            }
        }
        return result;
    }
    

     

    分离原则

     

    天下大事,分久必合合久必分。面对复杂的问题,考虑人脑的处理能力有限,有效的解决方案,就是大事化小,小事化了,将复杂问题拆分为若干个小问题,通过解决小问题进而解决大问题。

    分离的核心思路:

    1、架构视角

    结合业务场景对整个系统内若干组件进行边界划分,如,层与层(MVC)、模块与模块、服务与服务等。像现在流行的DDD领域驱动设计指导的微服务就是一种很好的拆解方式,通过水平分离的策略达到服务与服务之间的分离。

    图片

     

    架构设计视角下的关注点分离更重视组件之间的分离,并通过一定的通信策略来保证架构内各个组件间的相互引用。

    2、编码视角

    编码视角主要侧重于某个具体类或方法间的边界划分。比如Stream流的filtermaplimit,数据集在不同阶段按照不同的逻辑处理,并将输出内容作为下一个方法的输入,当所有的流程处理完后,最后汇总结果。

    一些不错分层案例:

    1、MVC模型

    2、网络 OSI 七层模型

    一个好的架构一定具有不错的分层,各层之间通过定义好的规范通讯 ,一旦系统中的某一部分发生了改变,并不会影响其他部分(前提,系统容错做的足够好)。

     

    契约原则

     

    天下事无规矩不成方圆,软件架构也是一样道理。动辄千日的大项目,如何分工协作,保证大家的工作能有条不紊的向前推进,靠的就是契约原则。

    契约式原则(DbC:Design by Contract)。软件设计时应该为软件组件定义一种精确和可验证的接口规范,这种规范要包括使用的预置条件、后置条件和不变条件,用来扩展普通抽象数据类型的定义。

    契约原则关注重点:

    • API 必须要保证输入是接收者期望的输入参数

    • API 必须要保证输出结果的正确性

    • API 必须要保持处理过程中的一致性。如果一个API被二次修改后,整个集群的服务器都要重新部署,保证服务能力状态的一致。

    如何做好 API 接口设计?

    1、接口职责分离。设计 API 的时候,应该尽量让每一个 API 只做一个职责的事情,保证API的简单和稳定性。避免相互干扰。

    2、 API 命名。通过命名基本能猜出接口的功能,另外尽量使用小写英文

    3、接口具有幂等性。当一个操作执行多次所产生的影响与一次执行的影响相同

    4、安全策略。如果API是外部使用,要考虑黑客攻击、接口滥用,比如采用限流策略。

    5、版本管理。API发布后不可能一成不变,很可能因为升级导致新、旧版本的兼容性问题,解决办法就是对API 进行版本控制和管理。

     


     

    关于我:前阿里架构师,出过专利,竞赛拿过奖,CSDN博客专家,负责过电商交易、社区生鲜、营销、金融等业务,多年团队管理经验,爱思考,喜欢结交朋友

    关注公众号 — 微观技术 ,查阅更多文章

    在这里插入图片描述

    欢迎大家扫描 ↓↓↓ 二维码,加个微信好友,多多交流
    在这里插入图片描述

     

     

    推荐阅读

    面试题:mysql 一棵 B+ 树能存多少条数据?

    学会这10个设计原则,离架构师又进了一步!!!

    亿级系统的Redis缓存如何设计???

    【高并发、高性能、高可用】系统设计经验

    人人都是架构师???谈何容易!!

    【万级并发】电商库存扣减如何设计?不超卖!

     

    展开全文
  • 设计模式(三)——面向对象设计原则

    千次阅读 多人点赞 2019-10-16 07:28:15
    设计模式需要遵循基本的软件设计原则。可维护性(Maintainability)和可复用性(Reusability)是衡量软件质量的重要的两个属性: 可维护性:软件能够被理解、改正、适应及扩展的难易程度 可复用性:软件能够被复用...

    设计模式需要遵循基本的软件设计原则。可维护性(Maintainability)和可复用性(Reusability)是衡量软件质量的重要的两个属性:

    • 可维护性:软件能够被理解、改正、适应及扩展的难易程度
    • 可复用性:软件能够被复用的难易程度

    面向对象设计的原则是支持可维护性复用,一方面需要实现设计方案或代码的复用,另一方面要保证系统易于扩展和修改,具有良好的可维护性。面向对象设计原则蕴含在各个设计模式中,是学习设计模式的基石,也是用于评价某个设计模式效果(Consequence)的重要指标。常见的面向对象设计原则包括:单一职责原则、开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则。

    1.单一职责原则

    单一职责原则:

    定义1:一个对象应该只包含单一的职责,并

    展开全文
  • 程序设计的六大原则-带图

    千次阅读 2018-04-19 16:38:45
    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。  原作者博客链接:...

    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。

      原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7

    一.单一职责原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7536542

      单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:

    单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。

          单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。

          单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

          下面通过一个简单实例来进一步分析单一职责原则:

    Sunny软件公司开发人员针对某CRM(Customer Relationship  Management,客户关系管理)系统中客户信息图形统计模块提出了如图1所示初始设计方案:

    1  初始设计方案结构图

    在图1中,CustomerDataChart类中的方法说明如下:getConnection()方法用于连接数据库,findCustomers()用于查询所有的客户信息,createChart()用于创建图表,displayChart()用于显示图表。

    现使用单一职责原则对其进行重构。

          在图1中,CustomerDataChart类承担了太多的职责,既包含与数据库相关的方法,又包含与图表生成和显示相关的方法。如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息,则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类,它不止一个引起它变化的原因,违背了单一职责原则。因此需要对该类进行拆分,使其满足单一职责原则,类CustomerDataChart可拆分为如下三个类:

          (1) DBUtil:负责连接数据库,包含数据库连接方法getConnection();

          (2) CustomerDAO:负责操作数据库中的Customer表,包含对Customer表的增删改查等方法,如findCustomers();

          (3) CustomerDataChart:负责图表的生成和显示,包含方法createChart()和displayChart()。

          使用单一职责原则重构后的结构如图2所示:

    2  重构后的结构图

    二.开闭原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7537584

      开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则。开闭原则由Bertrand  Meyer1988年提出,其定义如下:

    开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

          在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类

          任何软件都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时,我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则,那么可以非常方便地对系统进行扩展,而且在扩展时无须修改现有代码,使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大,软件寿命越来越长,软件维护成本越来越高,设计满足开闭原则的软件系统也变得越来越重要。

          为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。

          Sunny软件公司开发的CRM系统可以显示各种类型的图表,如饼状图和柱状图等,为了支持多种图表显示方式,原始设计方案如图1所示:

    1 初始设计方案结构图

          在ChartDisplay类的display()方法中存在如下代码片段:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    ......
    if  (type.equals( "pie" )) {
         PieChart chart =  new  PieChart();
         chart.display();
    }
    else  if  (type.equals( "bar" )) {
         BarChart chart =  new  BarChart();
         chart.display();
    }
    ......


          在该代码中,如果需要增加一个新的图表类,如折线图LineChart,则需要修改ChartDisplay类的display()方法的源代码,增加新的判断逻辑,违反了开闭原则。

          现对该系统进行重构,使之符合开闭原则。

           在本实例中,由于在ChartDisplay类的display()方法中针对每一个图表类编程,因此增加新的图表类不得不修改源代码。可以通过抽象化的方式对系统进行重构,使之增加新的图表类时无须修改源代码,满足开闭原则。具体做法如下:

          (1) 增加一个抽象图表类AbstractChart,将各种具体图表类作为其子类;

          (2)  ChartDisplay类针对抽象图表类进行编程,由客户端来决定使用哪种具体图表。

          重构后结构如图2所示:

    图2 重构后的结构图

          在图2中,我们引入了抽象图表类AbstractChart,且ChartDisplay针对抽象图表类进行编程,并通过setChart()方法由客户端来设置实例化的具体图表对象,在ChartDisplay的display()方法中调用chart对象的display()方法显示图表。如果需要增加一种新的图表,如折线图LineChart,只需要将LineChart也作为AbstractChart的子类,在客户端向ChartDisplay中注入一个LineChart对象即可,无须修改现有类库的源代码。    

           注意:因为xml和properties等格式的配置文件是纯文本文件,可以直接通过VI编辑器或记事本进行编辑,且无须编译,因此在软件开发中,一般不把对配置文件的修改认为是对系统源代码的修改。如果一个系统在扩展时只涉及到修改配置文件,而原有的Java代码或C#代码没有做任何修改,该系统即可认为是一个符合开闭原则的系统。

    三.里氏替换原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7540445

      里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。其严格表述如下:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1代换o2时,程序P的行为没有变化,那么类型S是类型T的子类型。这个定义比较拗口且难以理解,因此我们一般使用它的另一个通俗版定义:

    里氏代换原则(Liskov Substitution Principle, LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。

          里氏代换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。例如:我喜欢动物,那我一定喜欢狗,因为狗是动物的子类;但是我喜欢狗,不能据此断定我喜欢动物,因为我并不喜欢老鼠,虽然它也是动物。

          例如有两个类,一个类为BaseClass,另一个是SubClass类,并且SubClass类是BaseClass类的子类,那么一个方法如果可以接受一个BaseClass类型的基类对象base的话,如:method1(base),那么它必然可以接受一个BaseClass类型的子类对象sub,method1(sub)能够正常运行。反过来的代换不成立,如一个方法method2接受BaseClass类型的子类对象sub为参数:method2(sub),那么一般而言不可以有method2(base),除非是重载方法。

          里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象

          在使用里氏代换原则时需要注意如下几个问题:

          (1)子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里氏代换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义,如果一个方法只存在子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。

          (2) 我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

          (3) Java语言中,在编译阶段,Java编译器会检查一个程序是否符合里氏代换原则,这是一个与实现无关的、纯语法意义上的检查,但Java编译器的检查是有局限的。

          在Sunny软件公司开发的CRM系统中,客户(Customer)可以分为VIP客户(VIPCustomer)和普通客户(CommonCustomer)两类,系统需要提供一个发送Email的功能,原始设计方案如图1所示:

    1原始结构图

          在对系统进行进一步分析后发现,无论是普通客户还是VIP客户,发送邮件的过程都是相同的,也就是说两个send()方法中的代码重复,而且在本系统中还将增加新类型的客户。为了让系统具有更好的扩展性,同时减少代码重复,使用里氏代换原则对其进行重构。

          在本实例中,可以考虑增加一个新的抽象客户类Customer,而将CommonCustomer和VIPCustomer类作为其子类,邮件发送类EmailSender类针对抽象客户类Customer编程,根据里氏代换原则,能够接受基类对象的地方必然能够接受子类对象,因此将EmailSender中的send()方法的参数类型改为Customer,如果需要增加新类型的客户,只需将其作为Customer类的子类即可。重构后的结构如图2所示:

    图2  重构后的结构图

          里氏代换原则是实现开闭原则的重要方式之一。在本实例中,在传递参数时使用基类对象,除此以外,在定义成员变量、定义局部变量、确定方法返回类型时都可使用里氏代换原则。针对基类编程,在程序运行时再确定具体子类。

      另外补充一篇关于里氏替换原则的一篇博文:

      http://blog.csdn.net/zhengzhb/article/details/7281833

    四.依赖倒置原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7562783

      如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现。依赖倒转原则是Robert C. Martin1996年为“C++Reporter”所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作“Agile Software Development, Principles, Patterns, and Practices”一书中。依赖倒转原则定义如下:

    依赖倒转原则(Dependency Inversion  Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。

          依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。为了确保该原则的应用,一个具体类应当只实现接口或抽象类中声明过的方法,而不要给出多余的方法,否则将无法调用到在子类中增加的新方法。

          在引入抽象层后,系统将具有很好的灵活性,在程序中尽量使用抽象层进行编程,而将具体类写在配置文件中,这样一来,如果系统行为发生变化,只需要对抽象层进行扩展,并修改配置文件,而无须修改原有系统的源代码,在不修改的情况下来扩展系统的功能,满足开闭原则的要求。

          在实现依赖倒转原则时,我们需要针对抽象层编程,而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中,依赖注入是指当一个对象要与其他对象发生依赖关系时,通过抽象来注入所依赖的对象。常用的注入方式有三种,分别是:构造注入,设值注入(Setter注入)和接口注入。构造注入是指通过构造函数来传入具体类的对象,设值注入是指通过Setter方法来传入具体类的对象,而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型,在运行时再传入具体类型的对象,由子类对象来覆盖父类对象。

          下面通过一个简单实例来加深对依赖倒转原则的理解:

          Sunny软件公司开发人员在开发某CRM系统时发现:该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中,因此需要进行数据格式转换。在客户数据操作类中将调用数据格式转换类的方法实现格式转换和数据库插入操作,初始设计方案结构如图1所示:

    1 初始设计方案结构图

          在编码实现图1所示结构时,Sunny软件公司开发人员发现该设计方案存在一个非常严重的问题,由于每次转换数据时数据来源不一定相同,因此需要更换数据转换类,如有时候需要将TXTDataConvertor改为ExcelDataConvertor,此时,需要修改CustomerDAO的源代码,而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码,系统扩展性较差,违反了开闭原则,现需要对该方案进行重构。

          在本实例中,由于CustomerDAO针对具体数据转换类编程,因此在增加新的数据转换类或者更换数据转换类时都不得不修改CustomerDAO的源代码。我们可以通过引入抽象数据转换类解决该问题,在引入抽象数据转换类DataConvertor之后,CustomerDAO针对抽象类DataConvertor编程,而将具体数据转换类名存储在配置文件中,符合依赖倒转原则。根据里氏代换原则,程序运行时,具体数据转换类对象将替换DataConvertor类型的对象,程序不会出现任何问题。更换具体数据转换类时无须修改源代码,只需要修改配置文件;如果需要增加新的具体数据转换类,只要将新增数据转换类作为DataConvertor的子类并修改配置文件即可,原有代码无须做任何修改,满足开闭原则。重构后的结构如图2所示:

    2重构后的结构图

        

          在上述重构过程中,我们使用了开闭原则、里氏代换原则和依赖倒转原则,在大多数情况下,这三个设计原则会同时出现,开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,它们相辅相成,相互补充,目标一致,只是分析问题时所站角度不同而已。

    五.接口隔离原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7562842

      接口隔离原则定义如下:

    接口隔离原则(Interface  Segregation Principle, ISP):使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。

          根据接口隔离原则,当一个接口太大时,我们需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干。这里的“接口”往往有两种不同的含义:一种是指一个类型所具有的方法特征的集合,仅仅是一种逻辑上的抽象;另外一种是指某种语言具体的“接口”定义,有严格的定义和结构,比如Java语言中的interface。对于这两种不同的含义,ISP的表达方式以及含义都有所不同:

          (1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分将直接带来类型的划分。可以把接口理解成角色,一个接口只能代表一个角色,每个角色都有它特定的一个接口,此时,这个原则可以叫做角色隔离原则”。

          (2) 如果把“接口”理解成狭义的特定语言的接口,那么ISP表达的意思是指接口仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。在面向对象编程语言中,实现一个接口就需要实现该接口中定义的所有方法,因此大的总接口使用起来不一定很方便,为了使接口的职责单一,需要将大接口中的方法根据其职责不同分别放在不同的小接口中,以确保每个接口使用起来都较为方便,并都承担某一单一角色。接口应该尽量细化,同时接口中的方法应该尽量少,每个接口中只包含一个客户端(如子模块或业务逻辑类)所需的方法即可,这种机制也称为定制服务”,即为不同的客户端提供宽窄不同的接口。

          下面通过一个简单实例来加深对接口隔离原则的理解:

          Sunny软件公司开发人员针对某CRM系统的客户数据显示模块设计了如图1所示接口,其中方法dataRead()用于从文件中读取数据,方法transformToXML()用于将数据转换成XML格式,方法createChart()用于创建图表,方法displayChart()用于显示图表,方法createReport()用于创建文字报表,方法displayReport()用于显示文字报表。

    1 初始设计方案结构图

          在实际使用过程中发现该接口很不灵活,例如如果一个具体的数据显示类无须进行数据转换(源文件本身就是XML格式),但由于实现了该接口,将不得不实现其中声明的transformToXML()方法(至少需要提供一个空实现);如果需要创建和显示图表,除了需实现与图表相关的方法外,还需要实现创建和显示文字报表的方法,否则程序编译时将报错。

          现使用接口隔离原则对其进行重构。

          在图1中,由于在接口CustomerDataDisplay中定义了太多方法,即该接口承担了太多职责,一方面导致该接口的实现类很庞大,在不同的实现类中都不得不实现接口中定义的所有方法,灵活性较差,如果出现大量的空方法,将导致系统中产生大量的无用代码,影响代码质量;另一方面由于客户端针对大接口编程,将在一定程序上破坏程序的封装性,客户端看到了不应该看到的方法,没有为客户端定制接口。因此需要将该接口按照接口隔离原则和单一职责原则进行重构,将其中的一些方法封装在不同的小接口中,确保每一个接口使用起来都较为方便,并都承担某一单一角色,每个接口中只包含一个客户端(如模块或类)所需的方法即可。

          通过使用接口隔离原则,本实例重构后的结构如图2所示:

    2 重构后的结构图

         在使用接口隔离原则时,我们需要注意控制接口的粒度,接口不能太小,如果太小会导致系统中接口泛滥,不利于维护;接口也不能太大,太大的接口将违背接口隔离原则,灵活性较差,使用起来很不方便。一般而言,接口中仅包含为某一类用户定制的方法即可,不应该强迫客户依赖于那些它们不用的方法。

    六.迪米特法则

      原文链接:http://blog.csdn.net/lovelion/article/details/7563445

      迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),其定义如下:

    迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。

          如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。

          迪米特法则还有几种定义形式,包括不要和“陌生人”说话只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:

          (1) 当前对象本身(this);

         (2) 以参数形式传入到当前对象方法中的对象;

          (3) 当前对象的成员对象;

          (4) 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友;

          (5) 当前对象所创建的对象。

          任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

          迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度

          在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限在类的设计上,只要有可能,一个类型应当设计成不变类在对其他类的引用上,一个对象对其他对象的引用应当降到最低

          下面通过一个简单实例来加深对迪米特法则的理解:

          Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图1所示结构:

    1 初始设计方案结构图

          在图1中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

          现使用迪米特对其进行重构。

          在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如图2所示:

    2  重构后的结构图

    展开全文
  • 对于设计模式中七大原则的理解

    千次阅读 多人点赞 2021-08-28 01:14:28
    使用设计模式能够使我们开发的程序,易维护、可拓展,可...但是在23个设计模式的背后,还有7个开发原则去支撑着设计模式,保证23个设计模式能够易维护、可拓展,可复用。所以这篇文章来解开七大设计原则的神秘面纱。
  • 面向对象的五大基本原则

    万次阅读 2019-01-06 20:18:24
    面向对象的七(或五大原则,前五项)大基本原则:单一职责原则(SRP) 、开放封闭原则(OCP) 、里氏替换原则(LSP)、 依赖倒置原则(DIP)、 接口隔离原则(ISP)、迪米特法则(Law Of Demeter)、组合/聚合复用原则...
  • C++中定义的函数,必须有输入参数(或者说是,形参列表)。...在main函数中,当局部变量和全局变量同时存在的时候,优先引用局部变量,而不去引用全局变量。 "::"这个符号,可以直接来操作全局变量的。
  • 软件开发编程规范及原则

    万次阅读 2016-12-07 22:05:54
    头文件应向稳定的方向包含。   规则: A. 每一个.c文件应有一个同名.h文件,用于声明需要对外公开的接口; B. 禁止头文件循环依赖; C. .c/.h文件禁止包含用不到的头文件; D. 头文件应当自包含; ...
  • 设计模式之面向对象七大基本原则

    万次阅读 多人点赞 2015-04-27 16:25:48
    概述在运用面向对象的思想进行软件设计时,需要遵循的原则一共有7个,他们是:1. 单一职责原则(Single Responsibility Principle)每一个类应该专注于做一件事情。2. 里氏替换原则(Liskov Substitution Principle...
  • 稳定稳定性是第一前提,如系统崩溃恢复容灾备份这些,主要是一些数据保护的机制,还有就是程序参数的校验、异常的处理、事务的回滚、程序边界的设计(合理的边界划分可以避免服务的连锁崩溃)、对账机制等,这些...
  • 技术架构的战略和战术原则

    千次阅读 2021-10-19 14:09:06
    战略层设计原则 战略层的设计原则就是:合适原则、简单原则、演化原则。 1.1 合适原则 技术人员有一种很强的技术情怀,就是在做设计的过程中,很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界...
  • Xilinx FPGA全局时钟和局部时钟资源

    千次阅读 2019-09-12 09:40:10
    如果使用不当,不但会影响设计的工作频率和稳定性等,甚至会导致设计的综合、实现过程出错。Xilinx FPGA的7系列分为全局时钟(Global clock)和局部时钟(Regional clock)资源。目前,大型设计一般推荐使用同步时序电路...
  • 设计模式的7大原则

    千次阅读 2020-08-19 14:59:15
    其实不过是什么设计模式,都会尽量的遵循这最为核心的七大原则,那么是哪七大原则呢? 花了大把时间总结如果 对你有帮助清点赞,白嫖者 三天之内必得痔疮 一.设计模式常用的七大原则有: 1) 单一职责原则 2...
  • 这样,通过面向接口编程,我们的代码就有了很高的扩展性,降低了代码之间的耦合度,提高了系统的稳定性。 接口隔离原则 接口隔离原则的定义是 客户端不应该依赖他不需要的接口 换一种说法就是类间的依赖关系应该建立...
  • 设计模式-七大原则(图解一目了然)

    千次阅读 多人点赞 2020-09-30 20:32:44
    你是不是还在这样写代码?当头一棒,看完本文快回去检查检查你的代码吧! 单一职责原则 接口隔离原则 依赖倒转原则 里氏替换原则 开闭原则 迪米特法则 合成复用原则
  • java开发六大基本原则

    万次阅读 多人点赞 2017-11-27 10:12:49
    设计模式之六大原则(转载)  关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。 ...
  • python计算机视觉-局部图像描述子

    千次阅读 2022-03-29 15:23:29
    文章目录局部图像描述子Harris角点角点(corner points)角点检测算法HARRIS角点检测算法的基本思想Harris检测当中的数学表达Harris角点检测器响应函数Harris角点检测Harris角点检测的优缺点在图像间寻找对应点SIFT...
  • 1 软件设计模式的七大原则 1.1设计模式的目的 1.2设计模式七大原则 1.3单一职责原则 1.4 接口隔离原则(Interface Segregation Principle) 1.5 依赖倒转原则 1.6 里氏替换原则 1.7 开闭原则 1.8 迪米特法则 ...
  • 设计模式的六大原则

    万次阅读 多人点赞 2019-05-16 17:50:03
    一、单一职责原则(Single Responsibility Principle) 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则(Dependence Inversion Principle,...
  • 【设计原则】软件开发中的原则

    千次阅读 2018-07-05 19:51:36
    本文转自:http://www.cnblogs.com/pengdai/p/9151800.html在软件开发中,...本文主要将总结这些常见的原则,和具体阐述意义。 -----2018年1月 @pdai参考文章设计模式六大原则 http://www.uml.org.cn/sjms/201211...
  • 面向对象设计六大基本原则

    千次阅读 2020-12-22 23:20:34
    面向对象设计模式六大基本原则 本篇开始介绍面向对象设计思想 提示:写完文章后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录面向对象设计模式六大基本原则前言一、pandas是什么?二、使用步骤1.引...
  • 计算机视觉-局部图像描述子

    千次阅读 2022-03-29 22:08:36
    对于同一场景,即使视角发生变化,通常具备稳定性质的特征; 该点附近区域的像素点无论在梯度方向上还是其梯度幅值上有着较大变化; 2.角点检测算法基本思想 使用一个固定小窗口在图像上进行任意方向上的滑动...
  • 架构师必须知道的架构设计原则

    千次阅读 2019-02-11 11:01:05
    如果一个架构或设计原则已经存在15年,例如单一职责和依赖倒置原则,我可以预期它还有15年甚至更久的生命期。原则是比具体技术更抽象,更接近事物本质,也更经得起时间考验的东西。这些原则沉淀在架构师的脑海中,...
  • 爆裂:未来社会的 9 大生存原则

    千次阅读 2018-04-12 10:41:39
    力量在一个机构中的作用当然不消说,但是,如果我们承认未来的不确定性,以及局部失败的必然性,我们就需要一个能抵御灾难性故障的系统,而韧性能够帮助度过意想不到的风暴,使得一个机构真正变得更加活跃、强健和有...
  • 如果局部变量的名字和成员变量的名字相同, 要想在该方法中使用成员变量,必须使用关键字this 成员变量和局部变量的区别成员变量:1、成员变量定义在类中,在整个类中都可以被访问。2、成员变量随着对象的建立而...
  • 原则-开闭原则 对扩展开放,对修改封闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。 想要达到...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 42,100
精华内容 16,840
关键字:

局部稳定的原则