可复用面向对象软件的基础 -- 设计模式，以其可复用的设计初衷、精巧的逻辑思维被广大面向对象程序设计所追捧。但不少程序设计者却经常将思考的问题转换为遇到了什么场景就要用什么模式。这种八股文式的思维在某种程度上严重影响了程序设计的艺术性，并固化了程序设计者的思想，违背了设计模式的初衷。在本文中，作者总结了设计模式背后的核心思想，并提出了几个关键的设计原则，例如面向接口、封装变化、依赖倒置原则、只和朋友交谈等。程序设计者只需在程序设计时遵循这些原则，便会发现原来已经在使用某些设计模式了。
引题
GOF 的设计模式推出以后，受到程序员的热烈追捧，很多程序员不亦乐乎的埋头苦读甚至背诵其 23 个设计模式，并以熟悉设计模式而自豪。然而，在实际的程序设计中，很多程序员并未能把设计模式应用到自己的场景中。原因有很多，设计模式太多以至于常常被混淆；设计模式应用场景太局限或者程序员自己意识不到应用的场景。综合各种原因，根本原因只有一个，程序员并不能透彻理解，熟练应用设计模式的核心思想。笔者认为，设计模式并不是条条框框，设计模式也不是简单的 23 种。设计模式体现的一种思想是：尽可能的复用，而实现可复用的手段无外乎笔者总结的几个设计原则而已。
彻底的忘掉 GOF 的设计模式吧，程序设计应该是一门艺术，而不是备受束缚的那些模式。
原则一：封装变化
该原则的核心思想是，在程序设计中找出应用中可能需要变化之处，把它们独立出来以便以后可以轻易的改动或者扩充，而不影响不需要变化的部分。事实上如果您回过头去重新阅读设计模式的书籍，您会发现，封装变化几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让系统中的某部分改变不会影响其它部分。
我们举一个简单的例子，我们建立一个 Car 的基类，有两个继承类 Benz 和 BMW, 具体参见下图 1：
图 1. Car 的第一个实现
相信大部分人都会这么设计，但是这个设计有什么问题呢？我们看待问题需要以发展的眼光，假如科技发展了，所有的 Car 都可以飞了，怎么办？有人说，很简单，给 Car 加一个 protected 的 fly() 方法，这样 Benz 和 BMW 就都可以飞了，继承真伟大！好，那么如果我需要建立另外一个 Car 的子类玩具车（Toycar）, 我们知道玩具车可以 run, 但不能 fly 的。怎么办？还是好办，我们可以重载玩具车的 fly 方法，让他们什么都不干。那好，又一个子类来了，模型车（ModelCar）。模型车不能 run，不能 fly，好办，继续重载他们的这些方法。见下图 2：
图 2. Car 的第二个实现
如果我们有更多的 Car 的子类呢？有没有觉得有点繁琐，是的，我们需要重载太多的方法了。