设计原则-01

一.设计原则

1.六大设计原则

2.单一职责好处?

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

3.里氏替换?

只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生主任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应.

• 子类必须完全实现父类的方法
• 子类可以有自己的个性
• 覆盖或实现父类的方法时输入参数可以被放大 (重载和重写)
• 覆写或实现父类的万方法时输出结果可以被缩小

4.里氏替换优劣?

优点

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性;
• 提高代码的重用性;
• 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同;
• 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的;
• 提高产品或项目的开放性。

缺点

• 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法;

• 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束;

• 增强了耦合性。当父类的常量、变量和方法被修改时，必需要老 虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果–大片的的代码需要重构。

5.依赖倒置

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象;

• 抽象不应该依赖细节;

• 细节应该依赖抽象。

IDriver 司机开车(不区分车类型),ICar 车跑(区分车类型),2 个接口

6.依赖倒置的优点

• 依赖倒置原则可以减少类间的耦合性，
• 提高系统的稳定性，
• 降低并行开发引起的风险，
• 提高代码的可读性和可维护性。

7.依赖倒置的传递

• 构造函数传递依赖对象

• Setter 方法传递依赖对象

• 接口声明依赖对象

8.接口隔离

建立单一接口,不要建立臃肿庞大的接口。再通俗一点讲:
接口尽量细化，同时接口中的方法尽量少。与单一职责原则不是相同的吗?错，接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含
10 个方法，这 10
个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。专门的接口指什么?就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

• 接口要尽量小
• 接口要高内聚
• 定制服务
• 接口设计有限度的

9.迪米特法则

一个对象应该对其他对象有最少得了解,如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用；如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

该原则其根本思想，是强调了类之间的松耦合；类之间的耦合越弱，越利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

10.开闭原则

软件实体应该可以扩展，但不可修改。该原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的可维护、可扩展、可复用、灵活性好。

设计人员必须对于他设计的模块应该对哪种变化封闭做出选择，必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。最初编写程序时假设变化不会发生，当变化发生时，就创建抽象来隔离以后发生的同类变化，拒绝不成熟的抽象。