Introduction

         最近拜读了KentBeck的《实现模式》（《Implementation Patterns》）一书。这是一本关于如何写好代码的书，强调“如何编写出别人能够读懂的代码”。就像我最最崇拜的Martin Fowler所说的，“任何傻瓜都能写出机器能懂的代码。好的程序员应该写出人能懂的代码。”

         书中作者通过自己多年形成的编程习惯以及阅读既有代码的体验凝练成了编程中的价值观、原则和77种实现模式。最后Kent又结合自己开发JUnit时的经验，讲解了开发框架与开发应用程序的不同。

         本书被分为了7大块，来为所有的模式分类。

1.        INTRODUCTION：引言

         patterns：模式

         values & principles：价值观和原则

         motivation：动机

2.        CLASS：类

         similar logic：相似的逻辑

3.        BEHAVIOR：行为

         dividing logic：拆分逻辑

4.        METHODS：方法

         different data：不同的数据

5.        STATE：状态

         multi-valued data：多值数据

6.        COLLECTIONS：容器（介绍容器的资料太多了，这里就不多啰嗦了）

7.        FRAMEWORKS：框架

        Kent在INTRODUCTION提出了（patterns、values & principles、motivation）概念，这些是所有模式的理论基础，每看到一个模式都应该从这3方面来考虑。CLASS分为2部分来叙述，对应类中的方法和变量。CLASS中相似的逻辑（similar logic）可以抽象为BEHAVIOR，代表相同的动作，而一个动作是由几个步骤共同完成，获取这些步骤的过程就是拆分逻辑（dividing logic），步骤在类中具体就是METHODS方法。CLASS有多种状态（different data），每种状态又被称为STATE。有时候一个STATE不单单由一个数据来表述，而是汇聚了很多数据（multi-valued data）被称为COLLECTION。FRAMEWORKS（框架）和应用程序是不同的，Kent介绍了其中需要注意的不同项。

INTRODUCTION

模式—patterns

         一般我们都认为编程中多数功能是无法复制的，因为它们蕴含的业务含义是不同的。但是功能中的内容越接近纯技术化，其中的相似性就越多。绝大多数程序就都会遵循一组简单的法则。

l  多数情况下，程序是被阅读而不是编写

l  程序没有“完工”一说。

l  程序都由一组基本的语句和控制流概念组合而成

l  程序的阅读者需要理解程序——既从细节上也从概念上。

模式就是建立在这样的共性上的，从不同的问题中抽象提炼出其中的技术问题。面对不同的情况，需要的解决方案也不同。比如，我们要写一个循环，在处理实现了Iterator的数据时，我们就可以使用for-each，没有实现的情况下则不可以。这种不同的情况是一种约束，性能或是容易修改等这些要求都是约束，针对不同的约束，我们的实现模式也是不同的。所以说，模式是与约束相关联的，模式也可以说是针对某一约束的解决方案。

其实在实际情况中一个约束可能需要多种模式才可以解决，可见模式间应该是可以协作的。

价值观和原则—values & principle

         每个模式都承载着一点点理论。但实际编程中存在一些更加深广的影响力，远不是孤立的模式可以概括的。这里需要从另外的方面来讨论，values（价值观）和principle（原则）。

         Values是编程过程的统一支配性主题。与他人沟通的重要性、去除代码中的复杂性、保持开放的心态，这些就是我们的价值观——沟通、简单和灵活。

         价值观具有普遍的意义，但是往往难以直接应用；模式虽然可以直接应用，却是针对特定的场景；原则（principle）在价值观和模式之间搭建了桥梁。

         价值观、原则、模式，这3者相互补充，组成了一种稳定的开发方式。模式描述了要做什么，价值观提供了动机，原则把动机转化成了实际的行动。

价值观

         Kent认为价值观就是，沟通、简单和灵活。

沟通自不必说，闭门造车永远都是不可取的。通常我们认为沟通就是与同事、与客户等进行必要的交流，那么这里也是这样么？我认为以上的沟通很重要，但是这里强调的不是这个，这里的沟通应该是通过你的代码可以让别人了解到你的思想和目的。代码是这里的沟通载体，而不是别的。就像是Knuth所说，程序应该读起来像一本书一样。不光要自己在写的时候明白，更要别人或者是以后的自己明白。

简单。去掉多余的复杂性可以让那些阅读、使用和修改代码的人更容易理解。有些复杂性是内在的，它们准确的反映出所要解决的问题的复杂性。但更多的复杂性是由于我们忙着让程序运行起来，而留下的“手指印”。想想为了方便而随意增加的大量临时变量；由于需求变更而废弃的代码，等等这些都无形中增加了代码的复杂性。这里就要说到这本书没有提及的技术——重构。当然如果我们在程序一开始就保持简单的观念，那么后期的生产力会有极大的提升。

当然简单也是要分情况的，Kent也承认在应用程序中简单是非常重要的，但是在框架的开发中，简单也很重要但是我们更要注意的是它的扩展性。

简单与沟通通常是不可分割的。多余的复杂性越少，系统就越容易理解；在沟通方面投入的越多，就越容易发现应该被抛弃的复杂性。

灵活。是衡量那些低效编码和设计实践的一把标尺。程序的绝大部分开销都是在它第一次部署以后才产生的，所以程序必须要容易改动。

那么我们可以认为设计一个产品，使它可以应付绝大多数的变化，这应该是非常灵活的设计吧。事实上是这样么？想象中明天或许以后用得上的灵活，真的会发挥作用？以前写过不少这样的程序，花费很大的心思设计的扩展框架，在实际中却发现新增一个功能还是需要改动很多的代码。

个人认为，灵活这种东西就跟效率优化一样，只有真正遇到时才能做的足够好，当然这不是我为了偷懒而找的借口，事实却是如此。我们在做程序的时候要选择那种提倡灵活性并能够带来及时收益的模式。对于会立即增加成本但收效却缓慢的模式，最好还是让自己多些耐心，等到他真正需要的时候再拿出来。

所以简单性和大规模测试所带来的灵活性比专门设计出来的灵活性更为有效的原因。

原则

         原则可以解释模式背后的动机，它是由普遍意义的。就像是元素周期表可以帮助我们发现新的元素，清晰的原则也可以帮助我们引出新的模式。

以下是几种常见的原则：

1.        局部化影响

组织代码结构的时候，要保证变化只会产生局部影响。实现模式的一条最主要的动机就是减少变化所引起的代价。

2.        最小重复（DRY）

最小化重复在很多书中都有要求，DRY（Don’t repeat yourself）。重复不可预见，但是我们可以把程序拆分成许多更小的部分——小段语句、小段方法、小型对象和小型包，从而消除重复，提高复用率。

3.        将逻辑与数据捆绑

局部化影响的必然结果就是将逻辑与数据捆绑。把逻辑与逻辑处理的数据放在一起，如果有可能尽量放在一个方法中，或退一步放在一个对象中，最起码也要放在一个包下面。这样在修改的时候才能保证只会影响到局部。

4.        对称性

程序中处处充满了对称。比如，我们有一个add方法，那么就一定会有一个remove方法，一组方法会接受同样的参数，一个对象中所有的字段都具有相同的生命周期。识别对称性，一旦我们熟悉了其中一半，那么就能很快的理解另一半。

代码中对称性的表现，是无论什么地方，同样的概念都以同样的形式呈现。这个我觉得不是很必要，就像我提供一个读取方法，不代表我必须要提供一个设置方法。

5.        声明表达式

尽可能声明式地表达出意图。这个就相当于《Clean Code》中提到了命名问题，从命名中可以获取到足够的信息。这个蛮重要的，经常需要花很多时间去给变量或是方法命名，太难了。

6.        变化率

把具有相同变化率的逻辑、数据放在一起，把具有不同变化率的逻辑、数据分离。变化率具有时间上的对称性。比如，计算日常数据的代码和计算特定时间的代码，就应该分开，而不是放在一起。

变化率也适用于数据。一个对象中所有的成员变量的变化率应该差不多是相同的。可以将具有相同变化率的成员变量合并为一个对象变量。

动机—motivation

         软件设计应该致力于减少整体成本。软件成本可以被分解为开发成本和维护成本：

        

         其中维护成本又分为：

        

         从本质上来看，金钱的时间价值和未来的不确定性——相悖的。今天的一块钱比明天的一块钱更值钱，所以从原则上讲，我们的实现策略应该是尽量将支出推后。同样，由于不确定性，实现策略应该更倾向于带来即时收益而非长远收益。

         当然，我们在实际操作的时候，可以创建简洁的，易于阅读的代码来减少沟通、理解所带来的代价。清晰明确的代码带来即时收益：代码缺陷更少，更易共享，开发曲线更加平滑。