【设计模式】前奏之七大设计原则

重要性

1.对软件设计中普遍存在的（反复出现的）各种问题的解决方案
2.为了将来更好的扩展性，复用性，可用性，可读性，规范性进行相应处理

目的

1.解决耦合性，内聚性，可维护性，可扩展性，重用性，灵活性等多方面带来的挑战
2.为了提高代码的重用性，可读性，可扩展性，可靠性；使程序呈现高内聚，低耦合的特性

七大原则

概念：

程序员在编程时，应该遵守的原则

核心思想：

1.找出变化之处，把他们独立出来；隔离代码
2.针对接口编程
3.为了交互对象之间的松耦合设计而努力

七大原则概述

单一职责原则

概念：

一个类只能负责一项职责（并不代表只有一个方法）；如果类负责两个不同的职责：A1和A2，如果A1需求变更而改变这个类是时，可能造成A2执行错误，那么需要将这个类进行拆分

举例

常见单一职责实例：Web开发的Dao层，例如UserDao这个类只能去操作User用户表；如果这个类既能操作User表又能操作Order（订单表），那么需要将这个类进行拆分

原则和细节

1.降低类的复杂度，一个类只负责一个职责
2.一个类只负责一个事情，提高其可读性和可维护性
3.降低变更带来的风险
4.逻辑简单可以违背单一职责；类中的方法较少可以在方法中保持单一职责原则
5.少用if else if 这类代码；因为其增加了程序的耦合性；用类或方法的单一职责取代多分支结构

接口隔离原则

概念

客户端不依赖它不需要的接口；即一个类对另一个类的依赖应该建立在最小接口上

使用前举例

使用后举例

依赖倒转原则

原则

1.高层模块不应该依赖于底层模块，二者应该依赖于抽象（接口或抽象方法）
2.抽象不要依赖细节，细节应该依赖抽象
3.核心思想：面向接口编程
4.接口和抽象类的目的：制定好规范，而不涉及任何具体操作；把展现细节交给实现类去完成

依赖关系传递的方式

1.接口传递
2.基于成员变量
2.1构造方法传递
2.2setter方法传递

注意事项

1.底层模块尽量都要有抽象类或接口
2.变量的声明尽量是抽象类或接口；利于扩展和优化
3.遵循里氏替换原则

里氏替换原则

OO中所面临的问题

1.虽然继承不需要实现父类的所有方法，但是有可能会给父类已经实现的方法进行破坏
2.耦合度过高，修改了父类要考虑其子类

介绍

1.引用基类的地方必须能够透明的使用其子类
2.所以在子类中尽量不要重写父类的方法
3.在适当的情况下，通过聚合，组合，依赖来解决耦合度过高的问题；当然也可以将子类提上来跟父类同一级别，在继承一个公共的类

使用前举例

使用后举例

解决原子类提升后仍要依赖父类的问题，利用组合，在B中声明一个A类型的变量，使用即可

开闭原则（OCP）

解释

1.一个类、函数、模块应该对扩展（提供方）开放，对修改（使用方）关闭
2.软件需求变化，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有代码

迪米特法则

基本介绍

1.一个对象应该对其他对象保持最少的了解
2.类与类关系越密切，耦合度的越大
3.又称最小知道原则；被依赖的类不管多复杂，对外都是提供一个public方法进行调用即可
4.只与直接朋友通信
4.1直接朋友的概念
4.2依赖的类作为成员变量
4.3依赖的类作为方法传入类型
4.4依赖的类作为方法返回值类型
5.陌生类最好不要以局部变量的形式出现在类的内部

简单概括

自己的方法在自己类中实现，不要到依赖的那个类中的实现；比如A和B两个类，不可以在A中实现遍历B的数据，只能直接调用B提供好的遍历方法进行遍历

核心

降低类之间的耦合

合成复用原则

尽量使用合成，聚合的方式；而不是使用继承

如果B类要使用A类中的方法
1.依赖
1.1将A作为参数传到B的方法中
2.聚合
2.1 A作为B中的一个成员变量（属性）
2.1.1 可以通过setter方法赋值
2.1.2 可以通过直接new出来（组合的方式）