设计模式无招胜有招之设计目的

  为什么大家都说计算机是青春饭呢？这是因为大部分计算式知识是个纯粹的对错的知识。比如你学习C++编程，写个表达式，编译器能过就是对的，不能过就是错的。而这个对错的门槛是非常低的。任何人只要学过几天都会的。这样大量年轻人涌入这个行业，把老鸟给拍死了。新手和老手的价值貌似差不多。公司就不会以更高工资雇佣老鸟。

  而靠经验吃饭的人的知识是分好坏的。一个问题几个方案，那个也能解决。但是存在好坏。只有经过大量的实践，积累大量经验，你才能分出好坏，给出一个优化的选择。这样你的饭碗就能端的长久一点。

  设计模式就是个分好坏而不是对错的知识。那么怎么区分一个设计的好坏呢？得有个标准，标准又取决于你的目的。所以本文讲讲设计模式和设计目的的关系。

 

  设计目的有很多种，比如GOF的书名就是“Design patterns: elements of reusable Object-Oriented Software”，书名中提到了reusable可重用。

  我们常见的设计目的有：

    1)正确性：至少把功能先实现了，能给客户带来商业价值

     2)性能：   更快的速度，更高的CPU使用率，更少的内存占用

     3)可读性：这是一个巨大的话题，如何把代码写的其他人或者未来的自己一眼就能看懂是一个学问。

      4)可扩展性：当新的需求来的时候，只需要增加新的代码就可以了，无需修改已有的代码。

      5)可复用性：已经写好的代码，以后可以很方便的拿来复用。语言层面就是抽取公共的函数或者公共的类；在设计层面，就是要使得你的设计更抽象，从而能复用

      6)可维护性: 当需要修改代码的时候，只需要修改很少一部分，而不是类似的代码到处修改；也不是同一个功能放在不同的模块，要修改多个模块    

      7）可调试性：当产品出现问题的时候，如何更好的更快的找到问题的所在

      8）健壮性：异常处理能力。包括了我们不让系统发生异常的能力和当系统发生异常的时候，程序还能够正常运行下去，不至于整个程序死掉。也就是容错能力。

             比如：在GUI界面设计上，如果涉及一个下拉菜单给用户选择，那么不会出现异常的数值；如果设计了一个field，那么用户可以输入任何数值。在编写代码的时候，使用enum而不是int也是同样的意思。

      9）可移植性：在不同的系统中方便的移植

NOTE：上面的可扩展性，可复用性，可维护性的概念有时候能分来，有时候又比较模糊。本文中我把三个合并为一个可扩展性。他的内涵包括了上面三个概念。

如果目标是一个，那么很好办。我把各个设计打个分，分高的就是好的，分低的就是不好的设计。

但是这里的目标维度太多了，甚至是相互冲突的。这个时候就需要对这些目的进行优先级的排列了。

在上一章说过，当今计算机世界的逻辑变了。人是最昂贵的成本；市场竞争异常激烈；计算机渗透到了社会经济的方方面面。所有因素加起来决定了，好的代码的重要因素：正确性，可读性，可扩展性和可调试性。

从软件系统的角度看，软件的成本cost(total)= cost(develop) + cost(maintain)。现在软件越来越渗透到国民经济的各个方面，那些十分复杂由上千上万人维护的软件系统不断出现，且这些系统经常长达数十年的生命周期。于是cost(maintain)>>>cost(develop)。

且cost(maintain)= cost(read) + cost(change) + cost(test) + cost(deploy)。

如果代码写的好，简单易懂，那么cost(read)会减小，易读性成为追求的目标。

如果代码写的好，不用修改或者只改一小部分，那么cost(change)，cost(test)和cost(deploy)会减小，于是代码的可扩展性(OCP，灵活性flexible，复用reusable)成为追求的目标。

根据上面的分析，功能正确实现，可读性，可扩展性是排在优先级最高的三项。至于性能可以这么看。优先考虑前三项，当出现性能问题的时候，再调试性能即可。可移植性在某些系统中才会考虑。可调试性也是非常重要的特性，如果你设计的系统能够在一出现问题，那么马上就根据调试知道是什么问题，那么对系统维护是极好的。

那么设计模式会对这些目的有什么影响呢？

对正确性而言：没有影响。设计模式是对代码的整理，而不改变产品功能。

对性能而言：某些设计模式会引入很多中间类和中间步骤，因此在某种程度上而言，设计模式对性能有理论上的影响。在实际中，一般不予考虑。除非他真正影响到了性能。

对可读性而言：这是个双刃剑。现代的各种库，框架大量使用了设计模式中的模式。如果你不懂这些模式，这些产品和框架的可读性极差。因为你能看到的只是整个系统的一部分，你无法从整体上理解这个产品。如果你学过了设计模式，这个框架和产品的可读性有极高。根据每个模式的名字，就能帮你理解产品的一大块。

对可扩展性而言：主要的设计模式都是为了系统的可扩展性。

可调试性和健壮性而言：影响不大。

对可移植性而言：某系设计模式会把应用层和底层分开。如果产品想移植到新的平台，那么非常方便。