设计原则一些理解

设计原则一些理解

1. 设计原则贯穿在我们代码模块结构设计之中，核心思想为我们项目提供可扩展性做铺垫。
2. 怎么学习设计原则，结合我们代码设计实践来理解设计原则。结合到生活，应用场景来提炼。

单一职责原则(Single Responsibility Principle, SRP)

1. 一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因
2. 结合到我们生活与工作，货车的职责是拉货，公共汽车的职责是拉人，在日常生活中两个则是分开的，如果公共汽车又拉货，拉人，体验的确不太好。

开放-关闭原则

1. 是说软件的实体（方法，函数，类，模块）等，应该都是可以扩展的，但是原类信息是不可以修改。
2. 简单的描述 对于扩展是开放的（open of extension）；对于更改是封闭的（close for modificaiton）。
   3 在实践我们尽量依赖于接口与抽象，方便后面对其进行扩展。例子，业务需要一个运算方法，根据业务需要可能加，减
   剩，除。这种场景我们就可以抽象一个运算方法的类与方法，具体实现通过extends来实现。

依赖倒转原则(Dependency Inversion Principle, DIP)

1. 抽象不应该依赖于细节，细节应该依赖于抽象；说白了就是针对接口编程，不要对实现编程。
2. 概念听起来比较模糊，我们举例应该电脑的主板是高度模板，依赖于cpu，内存，硬盘的各个接口，所谓细节就是指cpu，内存的不同实现，
3. 意思也可以理解我们设计接口时候，不应该考虑细实现，而是整体抽象，扩展能力。

里氏代换原则(Liskov Substitution Principle, LSP)

1. 名字听起来复杂，其实道理很简单。
2. 定义，子类必须能够替代他们的父类类型，（意思就子类可以重写父类主要主要业务方法。）
3. 也可以这样描述，由于有里代换原则，才使得开放-关闭原则成为可能。

迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

1. 如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，
   扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。