学习设计模式，选定了三本书：
1. 设计模式精解 [美]Alan Shalloway & James R. Trott著
很基础的书，没有全面介绍23种模式，但是比较好懂，已经看完了。
2.设计模式-可复用面向对象软件的基础 GOF
公认的设计模式经典之作，不是很好懂，考验考验耐心吧，早些时候看了一半，就没看了，感觉收获很少，看完了第一本书后，现有捡起这本来从头看起，应该会有不少收获。
3.设计模式精解-GOF23种设计模式解析 一牛人写的手稿
这个是某牛人深刻理解和实际应用GOF那一帮理论后，写的一个手稿，感觉很不错，已经看完了，现又看准备一遍。
这儿准备记录些书中比较经典的文字，以及自己的些些理解。欢迎指正，共同探讨。
1、懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要。反之好像也可能成立。道可道，非常道。道不远人，设计模式亦然如此。
【排第一的当然是这一句了！道可道，非常道，顺便查了下这句话的出处老子《道德经》：“道可道也，非恒道也。名可名也，非恒名也。无名，万物之始也；有名，万物之母也。故恒无欲也，以观其眇；恒有欲也，以观其所徼。两者同出，异名同谓。玄之又玄，众眇之门。” 简单理解就是，“道”是可以意会的，但不可以言传。哈哈，感觉设计模式也是这样，往往只能由某个例子去通过“模式”的方法去解决某个问题，来说明模式的存在，在设计模式精解（第一本书里）最后几章，感觉作者是在拿着问题用一个一个的模式去套，违背了它的本意。正如下句所说：】
2、设计模式体现的是一种思想，而思想则是指导行为的一切，理解和掌握了设计模式，并不是说记住了 23 种（或更多）设计场景和解决策略（实际上这也是很重要的一笔财富），实际接受的是一种思想的熏陶和洗礼，等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开，这一切才是最重要的。
3、设计模式之于面向对象系统的设计和开发的作用就有如数据结构之于面向过程开发的作用一般，其重要性和必要性自然不需要我赘述。
4、Scott Mayer 在其巨著《Effective C++》就曾经说过：C++老手和C++新手的区别就是前者手背上有很多伤疤。是的在软件开发和设计的过程中，失败、错误是最好的老师，当然在系统开发中，失败和错误则是噩梦的开端和结束，因为你很难有改正错误的机会。因此，尽量让自己多几道疤痕是对的。
5、面向对象系统的分析和设计实际上追求的就是两点，一是高内聚(Cohesion),而是低耦合（Coupling）。这也是我们软件设计所准求的，因此无论是 OO 中的封装、继承、多态，还是我们的设计模式的原则和实例都是在为了这两个目标努力着、贡献着。
6、写这些文章，本身没有任何功利的杂念，只是一个原生态的冲动，反而很轻松的完成了。有心栽花未必发，无心之事可成功，世间的事情可能在很多的时候恰恰就是那样了。【作者的心态很令人欣赏....】
（1到6是择自设计模式手稿（第三本书））
7、设计模式是针对特定场景下的特定问题的可重复、可表达的解决方案。它不限于面向对象。不限于设计阶段，甚至不限于软件开发领域。
8、 从概念层次来看，一个对象是一系列的责任。 从规范层次来看，一个对象是一系列可以被其他对象或者该对象自己调用的方法。从实现层次来看，一个对象是一些代码和数据。
9、一个分析的缺陷：过早对细节投入太多的关心。分析者可能共同存在一个问题：在开发过程中过早的投入了细节分析。这也很自然，因为细节上的问题总是很具体很容易的。细节上的解决方案通常很明显，但这未必是一个最好的起点。应该尽可能晚地投入细节中去。
10、 设计模式源于建筑学和人类学。【延伸阅读著名建筑师Christopher Alexander的名著：The Timeless Way of Building，有中译本，已经看过，译本形如散文，很有意思。】
11、最主要的一点就是封装变化的概念，这是许多设计模式的主题。发现并封装变化点。
12、换句话说，如果变化点是问题领域中的特定的具体情况，共同点就定义了问题领域中将具体情况捆绑在在一起的概念。共同的概念将由抽象类来表现。而变化点分析发现的变化点将由具体类（使用特定实现的派生自抽象类的类）来实现。
13、在创建设计以处理变化的过程中，应该遵循两条基本策略：
·发现并封装变化点。
·优先使用对象组合，而不是类继承。
过去，开发这常常依靠扩展继承来为这些变化点定位。但是，第二条策略告诉我们，应该尽可能尝试使用对象组合。其意图是可以在独立的类中包含变化点从而使未来的变化不会影响现在的代码。
6点了，要回了，下次接着写吧.......o(∩_∩)o...