[GN] 设计模式——面向对象设计原则概述
提示：以下是本篇文章正文内容，下面案例可供参考
面向对象设计原则概述
单一职责原则
一个类只负责一个功能领域中的相应职责
类承担的职责越多，它被复用的可能性就越小
而且一个类承担的职责过多，就相当于将这些职责耦合在一起
开闭原则
一个软件实体应当对扩展开放，对修改关闭。即实体应尽量在不修改原有代码的情况下进行扩展。
里氏代换原则
所有引用基类(父类）的地方必须能透明地使用其子类的对象。
运用里氏代换原则时
- 应该将父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。
- 程序运行时，子类实例替换父类实例，可以很方便地扩展系统的功能，无须修改原有子类的代码
- 增加新的功能可以通过增加一个新的子类来实现。
依赖倒转原则
要针对接口编程，而不是针对实现编程。
在实现依赖倒转原则时
- 需要针对抽象层编程
- 具体类的对象通过依赖注入的方式 注入其他对象
其中接口注入是指通过实现在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。
例：
CustomerDAO 内调用TXT 和 Excel。需要手动更改代码
引入抽象层 只需要在CustomerDAO调用抽象类 并在配置文件xml定义调用TXT还是Excel
接口隔离原则
使用多个专门的接扣，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
即明确角色的业务 该接口方法仅服务该角色，不可多不必要的方法。
合成复用原则
尽量使用对象组合,而不是继承来达到复用的目的。
复用已有的设计
- 首先应该考虑使用组合 / 聚合，组合 / 聚合可以使系统更加灵活，降低类与类之间的耦合度
- 其次才考虑继承，在使用谜承时，需要严格遵循里氏代换原则，滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
因为继承时候，基类会暴露在子类下。
如上 CustomerDAO 继承了 DBUtil.
现需要更换数据库连接方式为 Oracle数据库
这样需要修改CustomerDAO 或者 DBUtil 违反了开闭原则
如上CustomerDAO 与 DBUtil是关联关系
采用依赖注入方式将DBUtil注入CustomerDAO
Oracle采用继承扩展DBUtil类。 根据里氏替换原则 DBUtil子类对象可以覆盖DBUtil对象
迪米特法则
软件实体应当尽可能少地与其他实体发生相互作用。
总结
本篇知识设计模式开篇基础知识。后面将会补充我学习过程中的设计模式