设计模式入门和策略模式

以往是代码复用，现在要通过设计模式来实现经验复用了。

OOP基础

• 抽象

• 封装

• 继承

• 多态



当涉及维护的时候，为了复用(reuse)目的而使用继承，结局并不完美。

继承存在的问题：

• 运行时行为不容易改变

• 改变会牵一发而动全身

• 超类中的逻辑会出现在所有的子类中

OOD原则

软件开发的一个不变真理：改变，不管当初软件设计得多好，一段时间之后，总是需要成长与改变，否则软件就会“死亡”。我们可以通过一些基本的原则来应对未知的变化，而不至于当变化来临时束手无策。

设计原则一

找出应用中可能需要变化之处，把他们独立出来，不要和哪些不需要变化的代码混在一起。

当我们把会变化的部分取出并封装起来时，以后便可以对这部分代码轻易地进行改动或扩充，并且代码变动引起的不经意后果会变少，系统将会变得更有弹性，因为这一部分的改变不会影响到其它部分。

设计原则二



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

针对接口编程的实际意思是，变量的声明类型应该是超类型(supertype)，这样我们就可以利用多态，直到执行代码的时候再来确定变量的实际类型。

设计原则三

多用组合，少用继承

我们在浴室洗澡，更具体来说是我们在浴缸中洗澡。那么可以说浴缸是一个浴室吗？这明显是不对的。此时说浴室中有一个浴缸才是正确的描述。

当我们将两个类结合起来使用时，它们之间的关系就是组合(composition)。使用组合也可以达到复用的目的，加上多态的能力，组合可以建立更具有弹性的系统。

策略模式(Strategy Pattern)

定义一组算法，分别进行封装，对这些算法抽象出一个行为，利用这个行为表示这些算法，在需要这些算法的地方使用抽象出的行为表示，从而可以让算法之间互相替换。

策略模式让算法的变化独立于使用算法的客户。

行话儿

朋友跟你说，我学会了一种编程方式，根据这种方式进行编程，我们需要为不同的东西定义一个类，在这个类中写入它所表示东西的特征，东西的状态在类中使用属性表示，东西能做的事情在类中使用方法体现。当我们需要某个东西的时候就要找到可以表示这个东西的类，然后利用这个类创建一个变量，就可以说我们有一个这个东西，我们就可以利用这个东西去做想做的事情。对了，这个东西有一个好听的名字：对象。

当朋友和你这样说的时候，你们两个至少有一个不懂得编程，不然就不会费这么大力气来表述这段文字。因为在编程的世界内是可以通过行话儿来对这些表述进行概括的，那就是：面向对象编程(OOP)。

行话就是同一领域内人士的共享词汇。

当我们学习设计模式的时候，我们学习的不只是模式的名称，而是一整套模式背后所象征的质量、特性和约束，模式的名称就是设计模式领域内的行话儿。