美文网首页设计模式之禅
《设计模式之禅》读书笔记-1.0-六大设计原则

《设计模式之禅》读书笔记-1.0-六大设计原则

作者: yeing | 来源:发表于2016-02-28 19:46 被阅读168次

    1.1 单一职责原则

    Single Responsibility Principle

    建议:

    接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化

    1.2 里氏替换原则

    Liskov Substitution Pronciple

    定义:

    只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常。

    规范:

    1. 子类必须完全实现父类的方法
    2. 子类可以有自己的个性
    3. 覆盖或实现父类的方法时输入参数可以被放大
    >参数不同相当于重载,不是覆写。    
    子类的参数范围如果比父类小,子类在没有覆写父类方法的前提下(将父类换为子类),子类方法可以被执行
    
    1. 覆写或实现父类的方法时输出结果可以被缩小
    >如果是覆写,子类的输出结果应 <= 父类的输出结果
    如果是重载,要求子类的输入参数宽于或等于父类的输入参数,也就是当将用父类的地方换为子类。这个方法也不会被调用。
    

    建议:

    采用里氏替换时,尽量避免子类的“个性”,一旦子类有“个性”,这个子类和父类之间的关系就很难调和了,把子类当做父类使用,自乐你的“个性”被抹杀——委屈了点;把子类单独作为一个业务来使用,则会让代码见的耦合关系变得扑朔迷迷离——缺乏类替换的标准。

    1.3 依赖倒置原则

    Dependence Inversioin Principle

    含义:

    1. 高层模块不应该依赖低层模块,两者都应该依赖其抽象
    2. 抽象不应该依赖细节
    3. 细节应该依赖抽象

    抽象:接口或抽象类。 细节:实现类

    依赖的三种写法:
    1、构造函数传递依赖对象
    2、Setter方法传递依赖对象
    3、接口声明依赖对象
    

    建议:

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

    1. 每个类尽量都有接口或抽象类,或者抽象类和接口

      基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置

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

      注意Utils工具类和 java实现类的clone方法

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

      类的继承层数尽量少

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

      如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要再覆写。类间的依赖是抽象,覆写了抽象类的具体方法,对依赖的稳定性会有一定影响。

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

      规则:接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化

    1.4、接口隔离原则

    Interface Segregation Principle

    Java接口的种类:

    1. 实例接口(Object Interface):Person zhangSan = new Person(); Person类就是zhangSan的接口
    2. 类接口(Class Interface):用interface定义的接口

    定义:

    1. 第1种:客户端不应该依赖它不需要的接口
    2. 第2种:类间的依赖关系应该建立在最小的接口上

    概括:

    接口尽量细化,同时接口中的方法尽量减少。与单一职责的区别:审视角度不同,单一职责要求的是类和接口职责单一,注重的职责,这是业务逻辑上的划分;接口隔离要求接口方法尽量少。职责相同,访问模块不同:尽量使用多个专门的接口,每个不同模块对应不同的接口。

    建议:

    1. 一个接口只服务于一个子模块或业务逻辑
    2. 通过业务逻辑压缩接口中的public方法,接口时常去回顾,尽量让接口达到“满身筋骨肉”,而不是“肥嘟嘟”的一大堆方法
    3. 已经被污染了的接口,尽量去修改,若变更风险较大,则采取适配器模式进行转化处理。
    4. 了解环境,拒绝盲从。

    根据经验和常识决定接口的粒度大小,接口粒度太小,导致接口数据剧增,开发人员呛死在接口的海洋里;接口粒度太大,灵活性降低,无法提供定制服务,给整个项目带来无法预料的风险。

    1.5、迪米特法则

    Law of Demeter ,也称为最少知识原则(Least Knowedge Principle)

    定义:

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

    四层含义:

    1. 只和朋友交流
    2. 朋友间也是有距离的
    3. 是自己的就是自己的

      有这样一个方法:放在本类中可以,放在其他类中也没错,那怎么去衡量呢?
      如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放在本类中。

    4. 谨慎使用Serializable

      VO:value object

    建议:

    1. 迪米特法则的核心观念就是类间的解耦,弱耦合,只有弱耦合后,类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类,导致系统复杂性提高。
    2. 在实际应用中,如果一个类跳转两次以上高才能访问到另一个类,就需要进行重构了。因为一个系统的成功不仅仅是一个标准或是原则就能够决定的,有非常多的因素。跳转次数越多,系统越复杂,维护就越困难,所以只要跳转不超过两次都是可以忍受的
    3. 迪米特法则要求类间的解耦,但解耦是有限度的。

    1.6、开闭原则

    Open Closed Principle

    定义:

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

    如何使用:

    ** 1. 抽象约束 **
    抽象是对一组事物的通用描述,没有具体的实现,也就表示它可以有非常多的可能性,可以跟随需求的变化而变化。因此,通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放。其包含三层含义:

    1.1. 通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法;
    1.2.参数类型、引用对象尽量使用接口或抽象类,而不是实现类;
    1.3.抽象层尽量保持稳定,一旦确定即不允许修改。

    ** 2. 元数据控制模块行为 **

    元数据:用来描述环境和数据的数据,通俗地说就是配置参数。参数可以从文件中获得,也可以从数据库中获得

    ** 3. 指定项目章程 **

    约定优于配置

    ** 4. 封装变化 **

    • a、将相同的变化封装到一个接口或抽象类中
    • b、将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中。
    • 封装变化:也就是受保护的变化(protected variations),找出预计有变化或不稳定的点,我们为这些变化点创建稳定的接口,准确地讲是封装可能发生的变化,一旦预测到有变化,就可以进行封装。

    相关文章

      网友评论

        本文标题:《设计模式之禅》读书笔记-1.0-六大设计原则

        本文链接:https://www.haomeiwen.com/subject/wvqgkttx.html