为什么需要面相对象
在历史进程中，我们由面相对象编程转向了面相对象编程，项目的规模也变得越来越大，其中有着必然的需求————改变。这里引用HeadFrist中的一句话:"不管软件设计的多好，一段时间之后，总是需要成长与改变，否则软件就会"死亡"。"紧接着就出现了面相对象这一概念:我们使用类来映射现实中的对象，通过对象来实现我们需要的功能，大家各辞其职，互不影响。这时候就不会出现牵一发而动全身的情况。软件的更新越来越快，实现的功能也越来越多。由于面相对象的支持，各个功能以模块化的形式在互联网上传播开来，大家再也不用去造重复的轮子，我们也有了更多时间做更加酷炫的事情。
为什么有了设计模式
很显然之前面相对象是一种强大而先进的思想，但是在开发过程中我们发现了很多问题。问题的来源也是改变，我们来举一个例子：
假设使用传统OO的方式，我们创建了一个超类Animal，它定义了所有的Animal产生的共同行为 makeSounds();run();mating();。 之后因为市场需求的变动我们需要给动物添加一个新的功能jump();(不改动就会死)。。这里传统OO有两种解决的方式：
继承
我们意识到OO继承的强大之处，只要我们使Animal()中增添新的方法jump(),问题就好像得到了解决。但是事实情况是：你需要检查你所有的子类，因为并不是所有的子类都对于此方法适用，比如蝎子、螃蟹、毛虫。这个问题也较容易解决：在子类中重写此方法，对于不适用的子类，重写它的空白方法jump(){}。到这里问题好像得到了解决，但是需要面临一个问题：每次我们创造一个新动物时都要气注意到底哪些需要覆盖，哪些不要。况且我们也没办法通过代码看出这个对象具体拥有哪些有效行为（需要检查哪些没有被覆盖）。
接口
这时候接口站了出来。他告诉我们只要你写一个jumpable()接口,让有能力的动物跳跃就可以了。看起来真是一个清晰的解决方法，但问题是接口是没有办法代码复用的。这意味着我们需要不断去实现每一个子类的具体功能————即使已经实现过了，真的是太可怕了。
之后呢
设计模式应运而生，它通过基于一些设计原则，告诉我们一种科学的规范，告诉我们如何进行抽象，如何实现某种功能。
