《敏捷软件开发》读书笔记5

1、  一般而言，我认为数据库是实现细节。应该尽可能地推迟有关这些细节的决策。不管这个特定的数据库是使用RDBMS、平面文件（flat file）或者OODBMS实现的，此时都是无关紧要的。现在，我仅仅对创建为应用程序的其他部分提供数据库服务的API感兴趣。随后，我会发现有关数据库的合适实现。

推迟有关数据库的细节是一项不常见、但却是很值得的实践。我们常常会一直等到对软件及其需要有了更多的知识时，才进行有关数据库的决策。通过等待，我们避免了把过多的基础结构放入数据库中的问题。我们更愿意仅仅实现刚好满足应用程序需要的数据库功能。P186

 

2、  在前面的章节中，我们已经使用了许多模式。我们常常是直接使用它们，而没有展示代码是怎样演化成使用模式的。这可能会让你认为模式就是一些以完整的形式插入到代码和设计中的东西。这不是我所建议的使用方式。我更喜欢朝着正在编写的代码需要的方向去演化代码。但我去重构代码以解决耦合性、简单性以及表达性的问题时，可能会发现代码已经接近于一个特定的模式了。此时，我把类和变量的名字改成使用模式的名字，并且把代码的结构更改为以更正规的形式使用模式。这样，代码就回归为模式。P261

 

3、  OBSERVER模式有两种主要模型：拉模型和推模型。P276

 

4、  OBSERVER模式的最大推动力来自开放封闭原则（OCP）。使用这个模式的动机就是为了在增加新的观察对象时可以无需更改被观察的对象。这样，被观察对象就可以保持封闭。P277

 

5、  在C++中，我们可以通过使Subject的析构函数是纯虚的或者使他的构造函数是受保护的来强制它的抽象性。P277

 

6、  结论：有人可能非常想说，调制解调器场景中的真正问题是最初的设计者设计错了。他们本应该知道连接和通讯是不同的概念。如果他们稍稍多做一些分析，就会发现这个问题并且改正它。所以，很容易把问题归结为不充分的分析。

       胡说！根本不存在充分分析这种东西。无论花多少时间试图去找出完美的软件结构，客户总是会引入一个变化破坏这个结构。

       这种情况是无法避免的。不存在完美的结构。只存在那些试图去平衡当前的代价和收益的结构。随着时间的过去，这些结构肯定会随着系统需求的改变而改变。管理这种变化的诀窍是尽可能地保持系统简单、灵活。

        使用ADAPTER模式的解决方案是简单和直接的。它让所有的依赖关系都指向正确的方向，并且实现起来非常简单。BRIDGE模式稍稍有些复杂。我建议在开始时不要使用BRIDGE模式，直到很明显可以看出需要完全分离连接策略和通信策略并且需要增加新的连接策略时，才使用这种方法。

        像往常一样，这里要讲的是，模式是既能带来好处又具有代价的东西。你应该使用那些最适合手边问题的模式。