七大设计原则
设计模式的基本概念
在软件工程中看，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。设计模式不是代码，而是某类问题的通用解决方案。设计模式代表着最佳实践。这些解决方案是众多软件人员的试错和总结。设计模式包含了面向对象的精髓，懂得了设计模式，就懂得了面向对象分析和设计的精要。
-
设计模式的本质：
- 提高软件的 “可维护性”，“通用性”，“可扩展性”，并降低"软件的复杂度"。
- 提高软件的 “可维护性”，“通用性”，“可扩展性”，并降低"软件的复杂度"。
-
设计模式的重要性
- 当项目开发完成时，如果客户提出新增功能怎么办?
==> 可扩展性 - 当项目开发完成时，程序员离职时，需要接受维护怎么办？
==> 可维护性，可读性， 规范性 - 在实际项目中用过什么设计模式？怎么使用的？解决了哪些问题？
- 设计模式在软件的什么位置？
面向对象OOP ==> 功能模块 （设计模式+数据结构+算法） ==> 框架（使用多种设计模式） ==> 架构(服务器集群)
- 当项目开发完成时，如果客户提出新增功能怎么办?
-
设计模式的目的
- 代码可重用性 ==> 相同功能的代码，不用多次编写。
- 代码可读性 ==> 编码规范性，便于其他人阅读和理解。
- 代码可扩展性 ==>当需要新增功能时，非常方便，易维护。
- 代码可靠性 ==>新增功能时，对原来的功能没有影响。
- 高内聚，低耦合 ==>对外呈现高内聚，低耦合。
-
核心思想：
- 找出应用中可能需要变化的地方，把它们独立出来。不要和那些不需要的代码混合在一起。
- 针对接口编程，而不针对实现类编程。
- 为交互对象之间的松耦合设计而努力。
24种设计模式
- 创建型模式
- 单例模式， 工厂方法模式，抽象工厂模式，原型模式， 建造者模式
- 结构型模式
- 适配器模式， 桥接模式， 装饰模式， 组合模式， 外观模式， 享元模式，代理模式
- 行为型模式
- 模板方法模式，命令模式，访问者模式， 迭代器模式，观察者模式，中介者模式， 备忘录模式，解释器模式，状态模式，策略模式， 责任链模式
- 模板方法模式，命令模式，访问者模式， 迭代器模式，观察者模式，中介者模式， 备忘录模式，解释器模式，状态模式，策略模式， 责任链模式
设计模式常用的七大原则
- 1、单一职责原则
- 2、接口隔离原则
- 3、依赖倒转原则
- 4、里氏替换原则
- 5、开闭原则OCP
- 6、迪米特法则（最少知道原则）
- 7、合成复用原则
一、单一职责原则
- 基本概念
对类来说，一个类只负责一项职责。如果类负责两个不同的职责：职责A和职责B，当职责A的需求发生改变时，则类中的代码发生改变，此时可能造成职责A和职责B的代码发生改变而造成错误，以及要重新进行单元测试。所以最好是将类进行单一职责的粒度进行分解。- 由于有多个职责，则由于改动而需要维护的代码更多
- 只有当类中逻辑足够简单，才可以在代码级别违反单一原则，只有当类中方法数量足够少时，可在方法级别上保持单一职责原则。
- 优点
- 降低了类的复杂度，一个类只负责一项职责。
- 提高类的可读性，可维护性。
- 降低了变更代码引起的风险。
- 通常情况下，我们应该遵循单一职责原则，除非逻辑足够简单，可以在放方法级别保持单一职责原则。
#b,c表示两类不同的功能
public class A {
public void b(){
...
}
public void c(){
...
}
}
==>
public class AB {
public void b(){
...
}
}
public class AC {
public void c(){
...
}
}
二、接口隔离原则
传统方法的问题和接口隔离原则的改进
- 传统方法的问题：
==>类A通过接口interface依赖B， 类C通过接口interface依赖类D，如果接口interface对于类A和类C不是最小接口，那么类B和类D就必须要去实现他们不需要的方法。
- 接口隔离原则：
==>将接口interface拆分成独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系，保持接口的最小依赖。这就是接口分离原则。
#类A通过interface E依赖类C， 其只依赖a(),b()方法
public class A {
private E e;
public A( E e ){
this.e = e;
this.e.a();
this.e.b();
}
}
#类C通过interface E依赖类D，且只依赖c(),d()方法
public class C {
private E e;
public C( E e ){
this.e = e;
this.e.c();
this.e.d();
}
}
#接口E
public interface E {
public void a();
public void b();
public void c();
public void d();
}
public class B implements E {
...
}
public class D implements E {
...
}
- 根据接口隔离原则进行改进
#类A通过interface E依赖类C， 其只依赖a(),b()方法
public class A {
private E e;
public A( E e ){
this.e = e;
this.e.a();
this.e.b();
}
}
#类C通过interface F依赖类D，且只依赖c(),d()方法
public class C {
private F f;
public C( F f ){
this.f = f;
this.f.c();
this.f.d();
}
}
public interface E {
public void a();
public void b();
}
public interface F {
public void c();
public void d();
}
public class B implements E {
...
}
public class D implements F {
...
}
三、依赖倒转原则
- 高层模块不应该依赖底层模块，二者都应该依赖其抽象。层之间依赖接口。
- 抽象不应该依赖细节，细节应该依赖抽象。
- 依赖倒转的核心思想：面向接口编程。
- 依赖倒转原则是基于以下的设计理念：
- 相对于细节的多变性，抽象的东西要稳定很多。以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多。在java中，抽象是指接口或者抽象类，细节就是具体的实现类。
- 使用接口或者抽象类的目的是制定好规范，而不涉及任何具体的操作，把战线细节的任务交给他们的实现类去完成。
依赖倒转的核心思想就是：面向接口编程。层与层之间通过接口来访问。不要在类的内部去new所依赖的对象，而是通过依赖关系传递到类内部来。
-
依赖关系传递的三种方式：
- 接口传递依赖；
public interface IOpenAndClose { public void open( TV tv ); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello aqy!"); } } public OpenAndClose implements IOpenAndClose { public void open( TV tv ) { tv.play(); } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(); iOpenAndClose.open( new AqyTV() ); } }- 构造方法传递依赖；
public interface IOpenAndClose { public void open(); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello AqyTV!"); } } public class OpenAndClose implements IOpenAndClose { private TV tv; public OpenAndClose( TV tv ){ this.tv = tv; } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(new AqyTV()); iOpenAndClose.open(); } }- setter方式传递依赖；
public interface IOpenAndClose { public void open(); public void setTV( TV tv ); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello AqyTV!"); } } public class OpenAndClose implements IOpenAndClose { private TV tv; public void setTV( TV tv ){ this.tv = tv; } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(new AqyTV()); iOpenAndClose.open(); } }
依赖倒转原则的注意事项和细节：
- 底层模块（被依赖或者被调用的组件）尽量使用抽象类或者接口，或者两者都有，程序稳定性会更好。
- 变量的声明类型尽量是抽象类或者接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利用实现接口的实体类进行扩展和优化。
- 继承时准寻里氏替换原则。
四、里氏替换原则
- 如果对每个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序在所有的对象O1都代换为O2时，程序的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说：素所有引用基类的地方都必须能透明的使用其子类的对象。即子类继承于父类的方法，行为保持一致，不要去重写覆盖。
- 在使用继承时，遵循里氏原则，在子类中尽量不要重写父类的方法，这样在版本迭代时，能保持较好的向下兼容性。
- 里氏原则告诉我们： 继承为让两个类之间的耦合增强，如果修改父类代码时，则会影响到子类的使用。修改子类继承于父类的代码，也会导致兼容性问题出现。在适当的情况下，可以通过聚合，组合，依赖来解决问题。
针对继承父类方法，又不得不重写父类方法的处理方案
- 可以解除继承关系，而是通过聚合，组合的方式来结局问题。
- 也可以让原有的父子继承关系解除，让不要重写的方法提取到一个公共的基类（编程一个虚拟类），让需要重写的方法在原来的父子类中分别实现。
子类重写父类方法的情形
public interface A {
public void a();
public void b();
public void c();
public void d();
}
public class B implements A {
public void a(){
System.out.println("B-a");
}
public void b(){
System.out.println("B-b");
}
public void c(){
System.out.println("B-c");
}
public void d(){
System.out.println("B-d");
}
}
public class C extends B {
public void a(){
System.out.println("B-a");
}
public void b(){
System.out.println("B-b");
}
public void c(){
System.out.println("C-c");
}
public void d(){
System.out.println("C-d");
}
}
遵循里氏替换原则的继承处理
- 将共有方法提取到公共的抽象类，不相同行为的方法单独实现。
public interface A {
public void a();
public void b();
public void c();
public void d();
}
public abstract class D {
public void a() {
System.out.println("D-a");
}
public void b(){
System.out.println("D-b");
}
public abstract void c();
public abstract void d();
}
public class B extends D {
public void c(){
System.out.println("B-c");
}
pulic void d(){
System.out.println("B-d");
}
}
public class C {
public void c(){
System.out.println("C-c");
}
pulic void d(){
System.out.println("C-d");
}
}
五、开闭原则
- 开闭原则： 最基础，最重要的设计原则。
==> 一个软件如类，模块和函数应该对提供方扩展开放，对使用方修改关闭。。用抽象构建框架，用实现扩展细节。 - 当软件需求发生变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。（扩展行为，不要轻易去修改已有的使用方中的代码）。
- 编程中遵循其他原则，以及使用设计模式的目的就是为了遵循开闭原则。提供方不允许修改代码。通过新增来扩展新功能。使用方不允许新增或者修改。（当做第三方库来对待使用方的代码）。
#通过接口传递依赖关系，根据多态来动态新增功能
public interface A {
public void setTV( TV tv );
}
public interface TV {
public void play();
}
public class IqyTV implements TV {
public void play(){
System.out.println("hello iqyTV");
}
}
public class B implements A {
private TV tv;
public void setTV( TV tv ){
this.tv = tv;
}
public static void main( String[] args ){
A a = new B();
a.setTV( new IqyTV() );
a.tv.play();
}
}
六、迪米特法则（最少知道原则）
- 一个对象应该对其他对象保持最少的了解。类与类之间的关系越密切，耦合度越大。
- 迪米特法则：又称为最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说： 对于被依赖的类，不管多复杂，都尽量将逻辑封装在类的内部，对外除了提供的必要的public方法，不对外泄露任何信息。
关于迪米特法则的简单定义：
- 只与直接朋友通信，且直接朋友也只提供public方法，不暴露内部逻辑。
关于直接朋友：
- 任何两个对象之间都有耦合关系，只要有耦合关系，就是朋友。耦合的方式有很多：依赖，关联，组合，聚合等。其中出现在成员变量，方法参数，方法返回值中的类称为直接朋友。出现在方法中的局部变量中的类不是直接朋友。（陌生类最好不要以局部变量的形式出现在类的内部）
七、合成复用原则
- 合成复用原则：
- 能用合成，聚合的方式，就不推荐用继承。
- 能用合成，聚合的方式，就不推荐用继承。
