• 五大原则 (单一职责、开放封闭、里氏代换、接口隔离、依赖倒置)


    单一职责原则-SRPSingle responsibility principle

        就一个类而言,应该只有一个导致其变化的原因。一个职责就是一个变化的轴线,一个类如果承担的职责过多,就等于将这些职责耦合在一起。一个职责的变化可能影响到其他职责。

            什么是职责?

                职责是“变化的原因”

                    例如某一个类现在同时具有“连接”和“通信”两种职责,根据单一职责原则,则可能存在两种处理方式:

                        1:“连接”和“通信”可能独立变化时

                            这种情况下,应该把职责分开。例如,应用的变化导致“连接”部分方法的签名(signature)发生了变化,那么使用数据“连接”的部分也需要重新编译,部署,这会相当麻烦,使得设计僵化。

                        2:“连接”和“通信”同时变化时

                            这种情况下,不必将职责分开。反而分离可能导致“不必要的复杂性”。

    开放封闭原则-OCPOpen-Closed Principle

        软件实体(类、模块、函数等)应该是可以扩展的,同时还可以是不必修改的,更确切地说,函数实体应该:

            1:对扩展是开放的

                当应用的需求变化时,我们可以对模块进行扩展,使其具有满足改变的新的行为--即我们可以改变模块的功能。

            2:对更改是封闭的

                对模块进行扩展时,不必改动已有的源代码或二进制代码。

        如果任何修改都需要改变已经存在的代码,那么可能导致牵一发动全身现象。

        事实上没有对所有变化的情况都封闭的模型,我们可以预测它们,或则直到我们发现他们才行动。

        如下面的示例:

           

        class ClentInterface{

            virtual void ServerFunc() = 0;

        };

        class server:public ClientInterface {

            int serverData;

        public

            void ServerFunc();

        }

        Class client{

            ClientInterface& ci;

        public

            client(ClientInterface &CI):ci(CI){

            }

            void useServer(){

                ci.ServerFunc();

            }

        };

        一个问题: 为什么上述的ClientInterface这个类要取这个名字,叫做AbstractServer岂不更好?

        其实这里面蕴含了一个思想:

            client类中更多的描述了高层的策略,而Server类中对这些策略的一种具体实现。而接口是策略的的一个组成部分,他跟client端的关系更加密切

        我们可以这样想问题;ClientInterface中定义了client期望Server做什么,而server具体类是对client这种要求的一种具体实现。

        OCP原则其实是要求我们清晰的区分策略和策略的具体实现形式。允许扩展具体的实现形式(开放),同时将这种扩展与策略隔离开来,使其对上层的策略透明(封闭)。

        一般情况下,无论模块多么“封闭”,都会存在一些无法对之封闭的变化,没有对所有变化的情况都封闭的模型

    接口隔离原则-ISP-Interface Segregation Principle

        不应该强迫客户依赖于他们不用的方法

        一个类的不内聚的“胖接口”应该被分解成多组方法,每一组方法都服务于一组不同的客户程序。

    依赖倒置原则-DIPDependency Inversion Principle

        高层模块不应该依赖于底层模块。二则应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。

        所谓“倒置”是相对于传统的开发方法(如结构化开发方法)中总是倾向于让高层模块依赖于底层模块而言的。

        高层包含应用程序的策略和业务模型,而底层包含更多的实现细节,平台相关细节等。高层依赖底层将导致:

            难以复用:底层改变一个软硬件平台将导致一些具体的实现发生变化,如果高层依赖底层,这种变化将导致逐层的更改。

            难以维护:底层通常是易变的。

        良好的OO体系结构都具有清晰的层次定义,每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。

        依赖关系倒置:下层的实现,依赖于上层的接口。

        接口所有权倒置:客户拥有接口,而服务者则从这些接口派生。

        依赖不倒置的开发

            自顶向下首先设计整个软件的分解结构

            然后首先实现下层的功能

            再实现上层的功能,并使上层调用下层函数

        依赖倒置的开发

            首先设计上层需要调用的接口,并实现上层

            然后底层类从上层接口派生,实现底层

        接口属于上层

    LisKov替换原则-LSP-Liskov Substitution Principle

        子类型Subtype必须能够替换他们的基类型(Basetype),若对每个类型S的对象O1,都存在一个类型T的对象O2,使得所有针对T编写的程序P中,用O1替换O2后,程序P的行为功能不变,则S是T的子类型。

    依赖倒置原则(DIP):Dependency Inversion Principle

        dependency |dɪˈpendənsi| noun 依赖

        inversion |ɪnˈvɜːʃn, American ɪnˈvɜːrʒn| noun 倒转 颠倒

        principle |ˈprɪnsəpl| noun 原则

    LisKov替换原则(LSP):Liskov Substitution Principle

        substitution |ˌsʌbstɪˈtjuːʃn, American -ˈtuː-| noun 代替 替换

    单一职责原则(SRP):Single responsibility principle

        responsibility |rɪˌspɒnsəˈbɪləti| noun 负责 义务 职责

    开放封闭原则(OCP):Open-Closed Principle

    接口隔离原则(ISP):Interface Segregation Principle

        segregation |ˌsegrɪˈgeɪʃn| noun 分离 分开

    substitute |ˈsʌbstɪtjuːt, American -tuːt| n 替身 vt 代替

    segregate |ˈsegrɪgəɪt| v 使孤立、使....分开、隔开

    signature |ˈsɪgnətʃə(r)| n 签名、签字

  • 相关阅读:
    接口继承与归一化设计
    继承part1
    组合
    静态方法,小结
    类方法
    Java 集合各个接口特性
    PV操作示例详解
    什么是Java序列化,如何实现java序列化
    String简单知识点
    intValue()、parseInt()和valueOf
  • 原文地址:https://www.cnblogs.com/yelongsan/p/6306838.html
Copyright © 2020-2023  润新知