飞奔在原野

很长一段时间前，看了一部分书，写了些笔记，由于某些原因中断了，今天重新拾起这本书，要继续看下去～～以下是上次的笔记，重新开始～    1. OO原则：        1.1.封装变化            指的是设计过程中，设计者应当充分考虑将来可能会发生变化的代码部分，将它们提取并封装起来。        1.2.多用组合，少用继承            即多使用has-a的关系，少用is-a的关系。若过分依赖继承，当父类的功能发生变化以后，将会影响到所有的子类。不利于代码的修改。而组合则是将各个功能独立

观察者 (Observer) 模式应该是使用得非常广泛的一个模式，在JDK中就有内建的观察者模式。首先我来说说什么是观察者模式。观察者模式：定义了对象之间一对多的依赖，这样，当一个对象改变时，它的所有依赖者都会收到通知并自动更新。很多场合下，我们都需要这样的一对多关系。设想一个GUI的计算器程序，当你按下一个按钮时，你需要按钮改变形状，更重要的，你需要将按键的信息传递给数据处理者。我们如果这样编程（伪码）：class Button { void pushed() { change

上回将之前看过的章节都大致梳理了一遍，回过头去看的时候，发现看不懂了。。太泛。从这篇文章起，我想一个个详细的说明，当是复习了。今天，先来讲述策略模式的故事。为什么要用策略模式？这一章从一开始便告诉我们，用继承来解决扩展问题并不是最好的办法，因为一旦你需要一个新的行为时，你就必须继承出一个新类，如此，代码便会在多个子类中重复，而由于我们不清楚到底有多少行为需要定义，设计之初的父类很可能要改变，而这种改变会导致其所有的继承者都受到牵连，这是很可怕！接下来，就是讨论该如何解决这个问题了。首先一个原则是，封装变化，

装饰者模式 (Decorator Pattern) 非常有趣，如果不是看过设计模式，看到这个模式的代码时一定大吃一惊：“这是什么东西？怎么这么多类！”是的，这就是这个模式的特别之处了，无数类摆在你面前，你无所适从。但这个模式是用来干什么的呢？用来管理大量同样类型但有细小属性差别的事物（我自己想的定义）。这也就注定了这个模式中，类的多样性。为什么会出现这么个模式？如果是我自己编程，我第一个想到的，肯定是继承。一个抽象类，其他各种功能的子类。这样设计是多么丑陋你应该一眼就看出来了，因为只要一个小小的改变，你就需

这一章，看得比较纠结，以前以为自己看懂了，回顾一下，组织语言想写博客的时候，发现还是没弄清楚。遂又上网查资料，发现一个比较好的网站： http://www.jdon.com/designpatterns/，就是广告多了点，说的还是很明白的。但我发现该网站上所说的工厂模式，似乎与Head First上讲述的模式有些出入，或者是侧重点不同？于是又在wiki上查找，再通过研究Head First的Java代码，终于发现，JDon上的说法确实是对的，即“这两个模式区别在于需要创建对象的复杂程度上”。不过简单工厂，似

命令模式其实比较简单，就是封装了请求，使得请求有统一的接口。其定义如下：将请求封装成对象，这可以让你使用不同的请求、队列，或者日志请求来参数化其他对象。命令模式也可以支持撤销操作。也就是说，命令模式可以通过一个抽象的命令类来扩展各种命令，接着，你可以使用诸如队列、链表之类的结构来很好的管理这些命令，使得命令对象包含的操作被有序的执行，以实现日志等功能。并且，由于命令对象能很清楚的知道它负责的请求需要的执行流程，它就能很轻易的实现撤销操作。命令模式具有上述的这些特性，使得它被广泛的使用于日志、撤销、菜单操作等

c++中的单件模式实现，列举各种方案，并分析其优劣。注：未考虑多线程情况。

详细介绍了适配器模式的两种实现方式：类适配器和对象适配器。并附上了经过测试的c++示例代码。简略介绍了外观模式。最后，对适配器模式、外观模式、命令模式做了些分析比较。

Oh yeah， 看到这个模式的时候，我很happy～因为我发现我居然在之前的编程中用过，而且是自己想出来的设计方式，很有成就感，哈哈。模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以在不改变算法结构的情况下，重新定义算法的中的某些步骤。从模板方法模式的定义中，我们就可以明确这个模式的实现方式了，即构造一个有算法骨架的基类，当你需要使用这个骨架的时候，继承该基类，并实现一些算法的细节。换句话说，基类定义了整个算法的框架。并实现某些通用的算法，使得需要这个框架的一些