1. 面向对象设计，为什么？

变化是复用的天敌！面向对象设计或者说使用了抽象原则的面向对象设计最大的优势在于：
抵御变化！

2. 重新认识面向对象

之前我们对面向对象的理解，包括封装、继承、多态，这是属于面向对象的底层思维理解。从抽象思维进行如下理解：

• 理解隔离变化
  • 从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。
• 各司其职
  • 从微观层面来看，面向对象的方式更强调各个类的“责任”
  • 由于需求变化导致的新增类型不应该影响原来类型的实现-所谓各负其责（多态更多的使用）
• 对象是什么？
  • 从语言实现层面来看，对象封装了代码和数据。
  • 从规格层面讲，对象是一系列可被使用的公共接口。
  • 从概念层面讲，对象是某种拥有责任的抽象。

3. 面向对象设计原则

设计原则要比具体某一个模式更为重要，后期讲到的模式当下已经不流行，某些已经被有些语言模式替代，甚至忘了也不重要。有了这些设计原则可以理解其他的模式，甚至可以设计自己的模式。

有一种错误的观点就是将设计模式当做算法去学习，后期可以看到两段代码非常相似，但是表达的模式是完全不同的，也有一种可能就是代码千差万别，但是设计模式是一样的。

所有的设计模式都是依赖这里所讲的设计原则，如果违背了设计原则，这种设计模式就是错误的。设计原则是一把尺子，可以用来衡量软件设计品质。
学习设计模式，一定不要只看代码的调用流程，如果你了解虚函数的调用机制，23种设计模式可以很快看懂，但是要掌握设计模式，就需要从设计原则的方向出发。

3.1 依赖倒置原则(DIP)

• 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) 。
• 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。

上面的话怎么理解呢，上篇中Mainform，依赖于Line和Rec。示意图如下图所示：箭头指向的代表了依赖

Mainform属于高层模块，Line和Rec属于底层模块，由于底层模块是容易变化的，高层模块是相当文档的，稳定的东西依赖于变化的东西，稳定的也就变成不稳定的，而应该将二者都依赖于抽象。

转换为第二种方式，示意图如下图所示：

Mainform依赖于Shape，Line和Rec也是依赖于Shape，Shape也就是上面讲到的抽象。

有些人喜欢在抽象类中使用子类，那就违背了抽象(稳定)不应该依赖于实现细节(变化) ，这是因为抽象应该是稳定的，如果依赖于一个实现细节，这个实现细节是容易变化的，就会变成，稳定的依赖于变化。

这里最关键的地方就是Line和Rec不稳定，容易变化，导致Mainform不稳定。

依赖倒置原则（ DIP）原则贯穿于所有的设计模式，这种原则是十分依赖抽象类的。

3.2 开放封闭原则(OCP )

• 对扩展开放，对更改封闭。
• 类模块应该是可扩展的，但是不可修改。

首先举一个现实生活的例子，有一个需求，需要做一套桌椅板凳，将需求提交给一个木器加工厂，加工过程中，使用场景是在一个办公大楼，所有的办公家具需要达到一个几级阻燃的标准，现在将新的需求告诉加工厂，木器加工厂如何应对呢？有两种应对方法：

1. 将做好的东西扔掉，重新再弄，这是一种改变的做法，不太好，浪费程度很大。
2. 聪明的木器加工厂，只需要刷一层防火涂料就可以了，他已经做了一些工作，只需要在前面基础上刷一层防火涂料，这是一种扩展的做法。

从代码的角度分析，上篇的代码中就使用了开放封闭原则，第二种方法就是以扩展的方式来应对需求的变化。

当需求变化的情况下，不要想着去更改，应该想着增加一些东西来应对需求的变化。

3.3 单一职责原则( SRP )

• 一个类应该仅有一个引起它变化的原因。
• 变化的方向隐含着类的责任。

有的时候，你会发现一个类会写的很臃肿，当一个类中放了太多的功能，也就隐含了多个责任，当隐含多个责任的时候就会出毛病，多个责任将你往不同的方向拉扯，用子类的时候，一会这个方向，一会那个方向。后期会讲到桥模式，装饰模式都会遇到类的责任问题，类的责任问题通常情况下，表现不是那么强烈，当遇到特殊的场合，类的责任是非常重要。

3.4 Liskov 替换原则 ( LSP )

• 子类必须能够替换它们的基类(IS-A)
• 继承表达类型抽象。

作为子类，所有需要父类的地方，都可以将子类传过去进行使用，这是天经地义的，但是具体实现时，就是会有人打破这个原则。
例如，有些程序员朋友喜欢在继承父类的子类中，发现父类中的三个方法，子类无法使用的，这个时候会在子类的3个方法中throw exception，这个做法就不对了。这就说明子类没有继承父类，或者说有可能是组合关系。

3.5 接口隔离原则 ( ISP )

• 不应该强迫客户程序依赖它们不用的方法。
• 接口应该小而完备。

“接口应该小而完备”中小的意思就是，不要把不必要的方法，public出去。如果只是子类使用的话，就protected。如果本类使用的话就private。如果真正有必要暴露的情况下，才将其public出去。
当你无节制的public出去，就很容易让外部的客户程序对其产生依赖，一旦产生依赖，接口就需要保持稳定。

3.6 优先使用对象组合，而不是类继承

• 类继承通常为“白箱复用”，对象组合通常为“黑箱复用” 。
• 继承在某种程度上破坏了封装性，子类父类耦合度高。
• 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

更准确的继承关系，其实是一种类属关系，比如说动物继承自生物，人又继承自动物。很多时候我们会错用继承，通常我们会有另外一种表白方法：对象组合（class A中包含class B，B可以是指针或者对象）。

3.7 封装变化点

• 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

当设计的素养逐步提升，是可以在软件领域划分分界层，从传统面向对象思维，封装就是封装代码和数据，但是封装更高层次就是封装变化点，一侧变化，一侧稳定。

3.8 针对接口编程，而不是针对实现编程

• 不将变量类型声明为某个特定的具体类，而是声明为某个接口。（针对业务类型，而不是像string等的具体类）
• 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
• 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。

上篇中：

	vector<Line> lineVector;
	vector<Rect> rectVector;

就违背了针对接口编程的原则，而

vector<Shape*> shapeVector;  //放抽象接口
......
shapeVector[i]->Draw(e.Graphics);  //使用接口的通用方法即可

针对接口编程的原则通常是与依赖倒置原则(DIP)相辅相成，违背了一个，通常也就违背了另一个。

不同设计原则是从不同角度看问题的。

面向接口设计的深入思考：产业强盛的标准：接口标准化!

接口的标准化，也就代表了工作的分配

4. 将设计原则提升为设计经验

• 设计习语 Design Idioms
  • Design Idioms 描述与特定编程语言相关的低层模式，技巧，惯用法。
• 设计模式 Design Patterns
  • Design Patterns主要描述的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式等方面。
• 架构模式 Architectural Patterns
  • Architectural Patterns描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间关系的规则。

下篇将会真正进入每一个模式，进入某一个模式之前，需要深入领会上面提到8大设计原则，只有这样才能灵活的运用某一种模式。