3、模式
    武功有招式，下棋有棋谱。不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。在软件开发领域，这种解决方案就被称为模式。

    "每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]

    这句话源自模式的鼻祖――Christopher Alexander。而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。而另一本值得阅读的著作，就是Martin Fowler所著的『分析模式』。

    在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。这非常的正常。但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。相信只要是开发过软件的人，都遇到过这种问题。于是，我们就希望能够看看其他人，是如何处理这种问题的。这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。

    这对你的吸引力是很大的。那么，我们谈论模式，模式来源于何处呢。注意，模式是针对某一类的问题的解。这里的问题，所指的就是需求。比如说，客户希望能够在软件中实现不同的税率计算方法，那么，我们很自然的就可以想到Strategy模式；当客户的产品有一个很复杂的单位换算机制的之后，我们也能够很自然的想到Quantity模式。使用模式，能够使我们迅速的把握需求的解决方法。另一方面，模式往往告诉我们比目前的问题更多的方面，因为模式都是大家的经验沉淀。如上所说，它还可以解决你目前没有遇到的问题。因此，我们还可以从模式中发现出更深的需求。

    另外一点也很重要，虽然它和需求的关系不大。模式往往都有一个模式名称。这就形成了一种沟通的语言。比如我们在下象棋的时候，只要说"马后炮"，谁都知道这是什么意思，绝对不需要呢详细的解说每一步棋子的走法。对于软件开发也是一样的。我和我的同伴会心的一笑，说："Factory Method。"两个人都能够理解这是什么意思，因为这是一种共通的语言，它代表了背后隐藏的各种类的关系和代码实现。这在软件开发中非常的重要。当然，这有个前提，大家都对模式有一个通透的了解。

    4、简单设计
    模式属于设计的一环，所以前面我们讨论的其实就是设计和需求的关系。这一小节我们还是讨论这个话题。但是侧重点有所不同。XP中有一个原则：KISS。不是kiss哦。它是Keep it simple and stupid的缩写。除了XP，其它的敏捷方法都提倡简单设计，反对过分设计（over build）。也就是说，针对目前的需求，设计目前的软件。

    很多的软件人员都是完美主义者，他们喜欢完美的设计，然后把这种设计提供给用户。这种思想就是过分设计的开始。不必要的功能浪费了客户的投资。我们在做需求的时候，很经常发现开发人员随意的向客户推销一些新功能，或是在设计时，过多的考虑未来可能出现的需求变动。 所以，简单设计的意思，就是要针对目前客户提出的需求进行设计，不要过多的考虑目前没有提到的功能。

    5、如何统一
    细心的读者看到这里可能已经是疑窦丛生了。一边是鼓励使用、设计最完美的方案；另一方面，又强调简单。似乎是自我矛盾。不错这其中是由矛盾的地方，但也有一致的地方。因此，在使用先进的模式和保持设计的简单性之间，我们需要权衡。 一次，我们看到了一个关于权限设置的模式，我们觉得这个模式非常的好，它提供了类似于UNIX操作系统那样的权限控制，可以很随意的增加组、用户，并能够在文件级别上设置权限。我们如获至宝，觉得这是一个非常有用的模式。于是，我们花了一些时间将之实现，并打算应用于新的软件中。

    在实际中，我们发现没有一个用户需要如此强大的功能，他们所需要的可能仅是密码控制，或是简单的用户管理。如此复杂的功能对他们来说没有任何的意义。完美的模式在现实中遭到了冷遇。

    实际上，用户目前不需要这项功能，并不意味着他以后不需要这项功能。用户的计算机程度提高的很快，我们估计，再过那么一两年，用户可能就非常需要这项功能来管理他那日益庞大的员工队伍了。但是目前，这项功能对用户来说，设置复杂，所以他们并不愿意接受这个"有价值"的功能。

    最后，我们想到了一个解决的办法，我们为这一项功能定义了一个通用的接口。通过这个接口，你可以实现复杂的功能，也可以实现简单的功能。总之，你只要是实现了接口的方法就行了。接口的方法很多，但是在目前的简单的实现中，可能就仅仅是一个返回语句，并没有很多的实现。相应的，用户的也仅仅需要使用简单的方法，诸如addUser()，updatePasswd()等。界面也做了简化的处理。

    通过这种方法，我们可以在用户需要的时候，替换掉权限模块，对其它的应用并不影响。当然，其中有很多的细节需要注意。在完成之后，我们还发现了另一个副产品：整个的权限控制模块是高内聚，低耦合的。

    模式，就好比螺帽的设计图纸，它规定了螺帽的技术规格，但是没有规定具体的尺寸。对应于不同的需要，我们可以设计出不同大小的螺帽以供使用。图纸只需要一份就可以了，并不需要为每一种尺寸的螺帽画一张图纸。

    因此呢，一个经历了实践检验的模式，往往功能强大。但是它可以有多种不同的实现。有哪一条法律规定你必须完全的实现一种模式呢。在实际使用中，你需要权衡模式使用的成本和效益。你会发现，在很多情况下，你还是实现了模式，但只是模式的一个框架，或一部分，但是这在目前就够用了。而当需求变动，或新的需求出现的时候，你可以很方便的在原有搭起的框架上添砖加瓦。一切都是那么的自然。比如，在一个进销存的软件中，存在一个运输选择算法，目前的运输途径就一种，但是很有可能会增加新的途径。这时候，你就决定采用Strategy模式。但是你只是实现了一个简单的框架，只有一个具体子类，来实现目前的算法。当新的运输途径出现时，你需要增加一个算法，你就可以再增加一个子类，只要实现的接口相同，改动是不会影响到系统其它的部分的。