设计模式理解 ----- 六大原则、23种设计模式(五大创建型模式、十一大行为型模式、七大结构型模式)

六大原则：

1. 单一职责原则 (可维护性、可读性、扩展性)

因为代码的变更是不可避免的，所以每一个功能，都应该完全分割开，不能对其他接口有影响。
好处：
1. 对系统的扩展性，维护性有很大的帮助。
2. 代码的阅读性提高很多，你就是你，他就是他（类的复杂性降低）。

目前的理解：
写代码的时候，经常因为麻烦，多个业务共用 “同一个实体类或同一个业务类” 导致修改的代码的时候，可能改一个地方，其他地方出问题。
最主要的是，时间久了看自己的代码也很吃力，其原因就是写混了，阅读性极差。

2. 里氏替换原则LSP-- (代码共享,每个子类都拥有父类的方法和属性)
   里氏替换原则: 为良好的继承,定义了一个规范。(违反LSP将使既有的设计不能封闭)

代码发展的过程中，功能会越来越多,我们不能随意的修改以前代码的功能，最好的做法是，新增一个功能。
好处：
1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
2. 提高代码的重用性。
缺点：
1. 继承是侵入性的。只要继承,就必须拥有父类的所有属性方法。
2. 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束。
3. 增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在缺乏规范的环境下,这种修改可能带来
   非常糟糕的结果——大段的代码需要重构。

理解：
当父类继承子类时,不要重写父类的方法。 (相对的。)

正常来说,当Programmer写好一个功能之后,是不容许其他任何人修改代码功能的,特别是那种开源代码,比如msyql连接驱动的代码。
比如：mysql的1个版本定义好了,连接数据库用 "ip:port:name:password"这种格式。
突然后面换了一个程序员维护这块代码,如果不遵循 里氏替换原则LSP ,再升级版本的时候,重写了这个方法，
比如换成 "ip,port,name,password"这种格式。
是不是之前用这个方法的公司，连接数据库都会出问题? 特别是,若这个功能是动态获取危害更大。

采用里氏替换原则的目的: 
    增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即时增加子类，原有的子类还可以继续运行。
    在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。

3. 依赖倒置原则 (面向接口编程)——OOD(Object-Oriented Design，面向对象设计)的精髓之一。

要实现依赖倒置原则，要有『面向接口编程』这个思维，掌握好这个思维后，就可以很好的运用依赖倒置原则。

依赖倒置原则要求：
1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象 
   解释:( 这里的高层与低层指的是:业务逻辑上的高低层，不是代码接口和实现类的高低层 )
2. 接口或抽象类不应该依赖,实现接口或继承抽象类而产生的类;
3. 实现类应该依赖接口或抽象类。

依赖关系的三种写法：
1. 构造函数传递依赖对象 
2. Setter方法传递依赖对象 
3. 接口声明依赖对象

进一步解释：
1. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备 
2. 变量的表面类型尽量是接口或者是抽象类 
3. 任何类都不应该从具体类派生 
4. 尽量不要覆写基类的方法 
5. 结合里氏替换原则使用

以上的规则通俗说就是：
1. 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，
2. 抽象类负责公共构造部分的实现，
3. 实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。 
4. 依赖倒置原则的核心就是:面向接口编程

勉强能理解,不知道什么时候能得其精髓。