设计原则

SOLID原则：是由罗伯特·C·马丁在21世纪早期引入，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。

单一职责原则(`Single Responsibility Principle`)

单一职责原则的英文名称是 Single Responsibility Principle，简称是 SPR，简单地说就是一个类只做一件事，这个设计原则备受争议却又极其重要。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。因为单一职责的划分界限并不是如马路上的行车道那么清晰，很多时候都是需要个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。这跟我们社会分工一样，一些人干这个，另一些人干那个，只有大家都这样做了，我们的社会才更和谐。

基本判断原则，就是一个特定的类，当确认以后，它的责任就确定了，不能增加它行为以外的功能。例如一般我们定义 API 接口的时候，如果这个接口干了很多事情，就是一些隐含的事情，我们就认为它设计没有遵循单一原则。

优点

类的复杂性降低，实现什么职责都有清晰明确的定义。
可读性提高，复杂性降低，那当然可读性提高了。
可维护性提高，可读性提高了，那当然更容易维护了。
变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

示例：

interface IHttp {
    sendRequest(request: Request): Response
}

开闭原则(Open-Close Principle)

开闭原则是 Java 世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。

开闭原则的定义是：一个软件实体类，模块和函数应该对扩展开放，对修改关闭。在软件的生命周期内，因为变化、升级和维护等原因，需要对软件原有的代码进行修改时，可能会给旧代码引入错误。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

在软件开发过程中，永远不变的就是变化。开闭原则是使我们的软件系统拥抱变化的核心原则之一。对扩展开放，对修改关闭这样的高层次概括，即在需要对软件进行升级、变化时应该通过扩展的形式来实现，而非修改原有代码。当然这只是一种比较理想的状态，是通过扩展还是通过修改旧代码需要依据代码自身来定。

还是上面的例子， HttpUrlConnImpl 和 HttpClientImpl 实现了 IHttp 接口，当我们实现 OKHttp 的时候就可以实现 HttpOKImpl，这样通过扩展的形式来应对软件的变化或者说用户需求的多样性，既避免了破坏原有系统，又保证了软件系统的可维护性。依赖于抽象，而不依赖于具体，使得对扩展开放，对修改关闭。开闭原则与依赖倒置原则，里氏替换原则一样，实际上都遵循一句话：面向接口编程。

里氏替换原则(Liskov Substitution Principle)

里氏替换原则本质就是继承和多态的应用。

继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。

它包含以下4层含义：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
子类中可以增加自己特有的方法
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

优点：

代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
提高代码的重用性。
提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，很多开源框架的扩展接口都是通过继承父类来完成的。
提高产品或项目的开放性。

缺点：

继承是侵入性的。只要继承，就必须拥有父类所有的属性和方法。
降低了代码的灵活性。子类必须父类的属性和方法，让子类自由的世界中多了些约束。
增强了耦合性。当父类的常亮、变量和方法被修改时，必须要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的后果---大量的代码需要重构。

示例：

// 可方便的替换http实现
class HttpClient {

    constrctor(http: IHttp) {
        this.http = http
    }

    doGet(reuqest) {
        this.http.sendRequest()
    }
}

接口隔离原则(Interface Segregation Principle)

接口隔离原则（interface-segregation principles，缩写：ISP）指明没有客户(client)应该被迫依赖于它不使用方法。接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。接口隔离原则(ISP)的目的是系统解开耦合，从而容易重构，更改和重新部署。接口隔离原则是在SOLID (面向对象设计)中五个面向对象设计(OOD)的原则之一，类似于在GRASP (面向对象设计)中的高内聚性。

很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构。采用接口隔离原则对接口进行约束时，要注意以下几点：

接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

依赖倒置原则(Dependence Inversion Principle)

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒置的中心思想是面向接口编程
依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类。使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

迪米特原则(Demeter Principle)

迪米特法则又叫 最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息

一个对象应该对其他对象保持最少的了解
类与类关系越密切，耦合度越大

# 设计原则

# 单一职责原则(Single Responsibility Principle)

# 开闭原则(Open-Close Principle)

# 里氏替换原则(Liskov Substitution Principle)

# 接口隔离原则(Interface Segregation Principle)

# 依赖倒置原则(Dependence Inversion Principle)