《实现模式》读书小记

《实现模式》一书作者Kent Beck，软件开发方法学的泰山北斗，是最早研究软件开发模式和重构方法论的先导者之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人。该书是一本关于如何撰写代码的书。本书中的模式，是基于 Kent 对现存代码的阅读以及他自己的编程习惯而形成的。这些模式来自他早年使用 Smalltalk 模式通过代码与其他开发人员进行沟通的过程。它们的级别相对设计模式较低，与 Larman 提出的 GRASP 模式处于同一粒度。本书中的模式试图为如何撰写大家都能看得懂的代码提供一个清晰明确的视角，并告诉你这些代码如何为人的需要和降低成本的需求提供保障。

编程中很多决策是无法复制的，但是当决策的内容越接近技术化，其中的相似性也越多。

大多数的程序都遵循一组简单的法则：

• 更多的时候，程序是在被阅读，而不是被编写；
• 在软件编码中，无绝对的“完成”一说，修改程序的投入可能会远远大于最初编写程序的投入；
• 程序是由一组基本的语句和控制流概念组合而成的；
• 程序的阅读者需要理解程序 — 既从细节上，也从概念上。有时从细节开始，逐渐理解概念，有时从概念开始，逐渐理解细节。

模式则是基于上述共性的法则而衍生的。而这些法则在编写程序的时候，则悄无声息的转变为编写者的压力（force），影响着每个程序的编写方式，因此模式的本质其实是压力（force）的模式。

一种编程理论

在现实生活中，哪怕在巨细靡遗的模式列表，也不可能涵盖编程中所遇到的每一种情况，你避免不了（甚至经常）会遇到上穷碧落，也找不到对应现成解决方案的情况。每一种模式都承载着一点点理论，但实际编程中存在一些更加深广的影响力，是孤立的模式所不能概括的。而价值观、原则、模式这三种元素组成的开发方式，相对比较稳定，更能契合大多数的解决方案。

贯穿于编程中的横切概念：价值观和原则。

• 价值观： 是编程过程中的统一支配性主题。沟通、简单和灵活
• 原则： 在价值观和模式之间搭建桥梁。编程原则可以演变出解决问题的方案等

模式表述要什么，价值观提供了动机，原则把动机转化成了实际行动。

有三种与价值观血脉相连的价值观，分别是：沟通、简单和灵活。看似有些互相矛盾，但是更多的时候却相得益彰，优秀的程序往往会为未来的扩展留下充分的选择余地，不包含不相关的元素，容易理解，便于阅读。

如果说人类的语言是为了加强联系，那么程序的阅读难易程度便是人类与程序世界沟通的桥梁。一份更加干净易读的程序，会更加高效清晰的表达编写者的想法，减轻阅读者的压力。那些把别人当做空气一样的编程方式，使得程序以及编写者慢慢退去颜色，就算耗尽心力搭建的城堡，也会无人问津。

程序应该读起来想读一本书，需要有情节和韵律，句子间应该有优雅的笑笑跌宕起伏。 — Knuth

在软件的生命周期内，第一次的部署决定着软件的绝大部分成本，对既有代码的阅读要比编写全新的代码耗时更长。因此注重代码的沟通力可以帮助我们改进思想，一方面投入更多的思考，阅读的同时调用脑细胞思考原有逻辑以及编写者是怎么想的；另一方面则是由于压力的减轻，因为在改变既有代码或者按照合适的方式编写代码的时候，自己知道是在务正业，做的是对的，自我认可感强。

在代码中，有复杂的，有简单的，而却出复杂性可以让阅读者、使用者以及后来修改代码的人更加理解，避免陷入猜想（猜想是代码修改者最痛恨，也最难受的）。但是在软件开发中，有些复杂性是难以避免的，这些复杂性反映出所要解决的问题的复杂性。但是有些复杂性的产生时因为我们忙着让程序运行起来，这种多余的复杂性降低了软件的价值，正确运行的可能性也降低了，在未来的改动中，改正确的成功率也降低了，回顾自己做过的事情，把麦子和糠分开，是编程不可或缺的一部分。

秉承在各个层次上都应该要求简单。对代码进行调整，删除所有不提供信息的代码。设计中不出现无关元素。对需求提出质疑，找出最本质的概念。去掉多余的复杂性后，就好像有一束光照亮余下的代码，你就有机会用全新的视角来处理它们。

在三种价值观中，灵活是衡量那些低效编码与设计实践的一把标尺。例如常量不应该使用环境变量去定义等等，程序是灵活的，但只有在发生变化的时候才可能真实需要某些设计。

灵活性的提高可能以复杂性的提高为代价。例如给用户提供一个自定义配置的选择，以提高灵活性，但是因为多了一个配置文件，编程时就要考虑这一点，所以也就变得复杂了。然而简单也可以促进灵活，例如如果可以找到取消配置选项但又不丧失价值的方式，那么程序的后续改动就更加简单了。

增进软件的沟通效果同样会提高灵活性，能够快速阅读、理解和修改你代码的人越多，它将来发生变化的选择就越多，即软件的灵活度也就提升了。

原则是另一个层次上的通用思想，比价值观更贴近与编程实际，同时又是模式的基础。原则可以解释模式背后的动机，它是有普遍意义的。

在对立模式间进行选择时，最好的方式就是用原则来说话，而不是让模式去争宠。

例如在学习新的编程语言，不必盲目的模仿现有的编程方式，更不用拘泥于其他语言中形成的习惯，可以根据自己对原则的理解快速去学习，即使在新鲜局面下仍能一以贯之。

局部化影响

在组织代码结构时，要保证变化只会产生局部化影响。

把修改的影响范围缩小到最小，代码就会有极佳的沟通效果，可被逐步理解，而不用一开始鸟瞰全景。

在实现模式的背后，最主要的动机就是减少变化所引起的代价，所以局部化影响这条原则也是很多模式的形成缘由之一。

最小化重复

最小化重复有助于保证局部化影响。

复制代码只是重复的一种形势，并行的类层次结构也是其一，同样破坏了局部化影响。如果出现修改一处概念需要同时修改两个或更多的类层级结构，就代表变化的影响已经扩散了，此时应该及时止损，停止一味地修改，而去重新组织代码，让变化只对局部产生影响。

重复往往不易被预见到，又是在出现很长时间后才会被察觉，重复不是错误也不是罪过，只是增加了变化的开销，提高了各类成本等。

重复解决：拆分程序为更小的单元 —- 小段语句、小段方法、小型对象和小型包等，从而慢慢消除重复。 大段逻辑很容易与其他大段逻辑出现重复的代码片段，于是就有了模式诞生的可能。

将逻辑和数据捆绑

局部化影响的必然结果就是将逻辑与数据捆绑。 把逻辑与逻辑所处理的数据放在一起，如果有可能放在一个方法中，或者放到一个对象中，最次放在一个包下，如果发生了变化，逻辑和数据很可能会同事被改动，如果放在一起，那么修改它们所造成的影响就会只停留在局部。

但是在一开始编程前，可能意识不到逻辑和数据的依赖，慢慢的演进中，发现此依赖彼，彼依赖其他的问题，此时就要考虑改如果组织代码结构，或者使用辅助类来解决依赖等。

声明式表达