设计模式预热篇——6大基本原则

简介: 设计模式预热篇——6大基本原则

本篇博客主要是复习设计模式的时候,对6大设计原则的总结,参考书籍《设计模式之禅》,讲设计模式的经典之作。


        java编程的6大设计原则如下:


            1.单一职责原则


            2.里氏替换原则


            3.依赖倒置原则


            4.接口隔离原则


            5.迪米特法则


            6.开闭原则


一、单一职责原则



             英文名称是Single Responsibility Principle ,简称是SRP。


             定义:应该有且仅有一个原因引起类的变更。


             好处:  1.类的复杂性降低,实现什么职责都有清晰明确的定义。


                          2.可读性提高。


                          3.可维护性提高。


                          4.变更引起的风险降低。


            最佳实践:接口一定要做到单元职责,类的设计尽量做到只有一个原因引起变化。


二、里氏替换原则



             英文名称,Liskov Substitution Principle ,简称LSP。


            定义:所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲就是只要父类能出现的地方,子类就可以出现,而且替换子类也不会产生任何错误或异常。


           4层含义:


                    1.子类必须完全实现父类的方法。


                    2. 子类可以有自己的个性。  


                    3.覆盖或实现父类的方法时输入参数可以被放大。


                    4.覆写或实现父类的方法时输出结果可以被缩小。


            好处:增强了程序的健壮性,版本升级时可以保持非常好的兼容性。即使增加子类,原有的子类还可以


继续运行。


            最佳实践:在实际项目中,每个子类对应不同的业务含义,使用父类作为参数,传递不同的子类完成不同的业务逻辑。但是要避免子类的”个性“,使的子类和父类之间的关系很难调好。


三、依赖倒置原则



             英文名称是Dependence Inversion Principle,简称DIP。


            3层含义:


                          1.高层模块不应该依赖底层模块,两者都应该依赖其抽象。


                           2.抽象不应该依赖细节。


                           3.细节应该依赖抽象。


               那么什么是抽象?什么又是细节呢?


                在java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类


就是细节,其特点是可以直接实例化,也就是可以加上一个关键字new产生一个对象。


              依赖倒置原则在java中的表现是:


                             1.模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,器依赖关系是通过接口或抽象类产生的。


                             2.接口或抽象类不依赖于实现类。


                             3.实现类依赖接口或抽象类。


                更加精简的定义就是”面向接口编程“——OOD(面向对象设计的精髓之一)。


               好处:可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。          


               依赖的三种写法:


                            1.构造函数传递依赖对象。(构造函数注入)


                             2. Setter方法传递依赖对象。(setter依赖注入)


                             3. 接口声明依赖对象。(接口注入)


                最佳实践:


                         依赖倒置原则的本质就是通过抽象使各个类或模块的实现彼此独立,不相互影响,实现模块间的松耦合。


                实现此原则只要遵循以下几个规则就可以:


                             1.每个类尽量都有借口或抽象类,或者抽象类和接口两者都具备。


                             2.变量的表面类型尽量是接口或者是抽象类。


                             3.任何类都不应该从具体类派生。


                             4.尽量不要覆写基类的方法。


                             5.结合里氏替换原则使用。


四、接口隔离原则



                 二种定义:


                          1.客户端不应该依赖它不需要的接口。


                          2.类间的依赖关系应该建立在最小的接口上。


                  通俗的说,就是接口尽量细化,保证其纯洁性,同时接口中的方法尽量少。


                   对接口进行规范约束时,包含以下4层含义:


                           1.接口要尽量的小——根据接口隔离原则拆分接口时,首先必须满足单一职责原则。


                           2.接口要高内聚——就是提高接口,类,模块的处理能力,减少对外的交互,这就要求在接口中尽量少定义public方法。


                           3.定制服务——单独为一个个体提供优良的服务,即只提供访问者需要的方法。


                           4.接口设计是有限度的——灵活,细化的同时会导致结构复杂,开发难度增加,可维护性低。


五、迪米特法则



                  也称为最少知识原则。


                  定义:一个对象应该对其他对象有最少的了解。通俗的讲,一个类应该对自己需要耦合或调用的类知道的最少。


                 4层含义:


                             1.只和朋友交流。——这里的朋友指有耦合关系的对象。


                             2.朋友间也是有距离的。


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


                                 所以要尽量减少public方法和属性,多使用private,protect等访问权限。


                              3.是自己的就是自己的。


                                                  如果一个方法放在本类中,即不增加类间关系,也对本类不产生负面影响,就放置在本类中。


                               4.谨慎使用Serializable


                   最佳实践:


                          迪米特法则的核心观点就是类间解耦,弱耦合,提高类的复用率。


六、开闭原则



            重要性: 是最基础的原则,是精神领袖。              


            定义:一个软件实体如类、模块和函数应该对外扩展开发,对修改关闭。


                      什么是扩展?即不修改原有代码,通过继承或实现接口形成新的类,完成新的需求,而不在已完成的代码上进行修改。


              好处:


                      1.减少了测试的工作量。


                       2.提高复用性。


                       3.提高可维护性。


                       4.符合面向对象开发的要求。


               如何使用开闭原则?


                       1.抽象约束。


                                通过接口或抽象类可以约束一组可以变化的行为,并且能够实现对扩展开放,其包括三次含义:


                                第一,通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法。


                                第二,参数类型,应用对象尽量使用接口或抽象类,而不是实现类。


                                第三,抽象层尽量保持稳定,一旦确定即不允许修改。    


     


                       2.元数据控制


                                   元数据,就是用来描述环境和数据的数据。通俗地说就是配置参数。


                                   通过扩展一个子类,修改配置文件,完成了业务变化。


                       3.制定项目章程


                                  对项目来说,约定由于配置。比如,约定统一使用注解来实现注入。


                       4.封装变化


                                  包含两层含义:


                                        第一,将相同的变化封装到一个接口或抽象类中。


                                       第二,将不同的变化封装到不同的接口或抽象类中。


                                 准确的讲是对可能发生的变化进行封装。

目录
相关文章
|
4月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
4月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
6月前
|
设计模式 供应链
设计模式六大原则之迪米特法则
设计模式六大原则之迪米特法则
|
3月前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
4月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
4月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
4月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
6月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
46 2
|
6月前
|
设计模式 Java 数据库
深入理解设计模式六大原则
深入理解设计模式六大原则
|
6月前
|
设计模式 数据可视化 程序员
设计模式学习心得之前置知识 UML图看法与六大原则(上)
设计模式学习心得之前置知识 UML图看法与六大原则(上)
48 0