面向对象的七种设计原则

1.SRP:Single responsibility principle)单一职责原则又称单一功能原则

  核心:解耦和增强内聚性(高内聚,低耦合) 

  描述:

    类被修改的几率很大,因此应该专注于单一的功能。如果你把多个功能放在同一个类中,功能之间就形成了关联,改变其中一个功能,有可能中止另一个功能,这时就需要新一轮的测试来避免可能出现的问题。

                    单一职责的潜台词是:拆分到最小单位,解决复用和组合问题。

2.开闭原则(OCP:Open Closed Principle)  

  核心思想:对扩展开放,对修改关闭。即在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展。

  根据开闭原则,在设计一个软件系统模块(类,方法)的时候,应该可以在不修改原有的模块(修改关闭)的基础上,能扩展其功能(扩展开放)。

  扩展开放:

    某模块的功能是可扩展的,则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。

  修改关闭:

    某模块被其他模块调用,如果该模块的源代码不允许修改,则该模块修改关闭的。软件系统的功能上的稳定性,持续性要求是修改关的。

          开闭原则是设计模式的第一大原则,它的潜台词是:控制需求变动风险。缩小维护成本。

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

  核心:    

    (1)在任何父类出现的地方都可以用他的子类来替代(子类应当可以替换父类并出现在父类能够出现的任何地方)子类必须完全实现父类的方法。在类中调用其他类是务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则。

    (2)子类可以有自己的个性。子类当然可以有自己的行为和外观了,也就是方法和属性

    (3)覆盖或实现父类的方法时输入参数可以被放大。即子类可以重载父类的方法,但输入参数应比父类方法中的大,这样在子类代替父类的时候,调用的仍然是父类的方法。即以子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。

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

                 里氏替换原则的潜台词是:尽量使用精准的抽象类或者接口。

4.依赖倒转原则(DIP:Dependence Inversion Principle)

  别名:依赖倒置原则或依赖反转原则

  核心:要依赖于抽象,不要依赖于具体的实现

  三种实现方式:

     (1)通过构造函数传递依赖对象

     (2)通过setter方法传递依赖对象

     (3)接口声明实现依赖对象

                  依赖倒置的潜台词是:面向抽象编程。解耦调用和被调用者。

5.接口分离原则(ISP:Interface Segregation Principle)

  核心思想:不应该强迫客户程序依赖他们不需要使用的方法。

  接口分离原则的意思就是:一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口当中.

  分离接口的两种实现方法:

    (1)使用委托分离接口。(Separation through Delegation)

    (2)使用多重继承分离接口。(Separation through Multiple Inheritance)

                    接口隔离原则的潜台词是:拆分,从接口開始。

6.合成复用原则(CRP:Composite Reuse Principle)

  核心思想:

    尽量使用对象组合,而不是继承来达到复用的目的。该原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分:新的对象通过向这些对象的委派达到复用已有功能的目的。

    复用的种类:

        (1)继承

        (2)合成聚合

    注:在复用时应优先考虑使用合成聚合而不是继承

                组合聚合复用原则的潜台词是:我仅仅是用你的方法,我们不一定是同类。

7.迪米特原则(LOD:Law of Demeter)又叫最少知识原则,一个软件实体应当尽可能少的与其他实体发生相互作用

      因为:

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

      所以:

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

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

                迪米特原则的潜台词是:不和陌生人说话,有事去中介。

              迪米特法则:一个软件实体应当尽可能少的与其他实体发生相互作用。

原文地址:https://www.cnblogs.com/fl72/p/8277377.html