昨晚11点, 第三次读完《明朝那些事儿》, 彻夜未眠.
LD 并不是个聪明的人, 前两次均未理解所谓历史 所谓宿命 所谓自由. 这半年, 从09年9月, 第三次读《明》, 完全不同的感受, 石悅的历史观也许是悲观的, 正如他如是说. 然, LD 是悲愤的!
可以活得唯唯缩缩, 可以轰轰烈烈, 也可平平淡淡, 人之所以为人, 就是与别个不同. 10月, LD 曾慕名前往于谦祠, 旁边帅GG 惊呼: 于谦? 谁啊? 好像以前学过… 是啊~ 我也是. 强人只是那么一瞬间, 那一刻 绽放比凡人璀璨的花火, 之后殒灭为尘秽, 清澈、汙浊平凡无异.
生活的目标 一点足矣, 开心. 礼义廉耻 忠义孝廉 儿戏 儿戏, 二十几年来, 从没有这么坚定, 从没有这么澄净. 引用《火鳳燎原》中那句话: 属于我的这个年代, 将比任何朝代来得久远!
上周基本无事,所以上班时间偷空把 DsCache 进化成加强版 2.0.r31. 这次主要加入了生成静态HTML 和 Memcached 内存缓存 这俩小崽子, 不错不错, 无痛转换缓存方式.
DsCache 主页: http://code.google.com/p/dscache/
2.0.r31 版源码: http://dscache.googlecode.com/files/DsCache_2.0.r31.tar.gz
使用举例:(源码目录下 test2)
“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。” ── 建筑家 Christopher Alexander
模式 是在某情境 (context) 下，针对某问题的某种解决方案。
情境 就是应用某个模式的情况。这应该是会不断出现的情况。 [ 我要如何准时上班？ ]
问题 就是你想在某情境下达到的目标，但也可以是某情境下的约束。 [ 我将钥匙锁在车里了。]
解决方案 就是你所追求的： 一个通用的设计，用来解决约束，达到目标。 [ 打破窗户，进入车内，启动引擎，然后开车上班。]
成本 解决方案所花费的才力 (财力)。 [ 窗户的价值。]
模式是解决问题的方法，用于不用无所谓; 但当我们应用模式时，就应该考虑怎么才能更好的解决问题 (反之，去除模式)。
模式的模式:
模式通常被一起使用，并被组合在同一个设计解决方案中。
复合模式在一个解决方案中结合两个和多个模式，以解决一般或重复发生的问题。
MVC (Model-View-Controller) : 模型利用“观察者”让控制器和视图可以随最新的状态改变而更新。另一方面，视图和控制器则实现了“策略模式”。控制器是视图的行为; 视图内部使用组合模式来管理显示组件。
FleaPHP 的MVC解释图 很好的标示了这种模式：
OOP村齐家的少爷喜欢上了尹家的小姐，但有鉴于礼法，双方长辈反对， 两个年轻人不能长时间见面。于是齐少爷的书童 和 尹小姐的丫环当起了连络人。 尹小姐想多了解齐少爷，派丫环去探探舌漏，丫环找到从小就跟着齐家少爷的书童，书童乘机说尽好话…… [ 这里丫环就是小姐的代理; 小姐要了解少爷，所以小姐是客户对象，丫环是客户辅助对象，书童是服务辅助对象，少爷是服务对象; 这个模式叫远程代理。]
齐少爷和尹小姐书信来往好久了，齐少爷记不得以前写过什么良言美句，书童会意，把保存的书信拿了出来参考。[ 书童就好比缓存代理 ]
齐家毕竟是大户人家，也指望齐少爷他日金榜题名，齐老太太天天来检查齐少爷的读书情况。这天少爷溜出去与尹小姐私会，书童穿了少爷的衣服在窗后装模作样，老太太看到窗影很高兴。 [ 虚拟代理 ]
书童身材和少爷还是比较相似的，少爷毕竟是老爷的儿子，萧峰和萧远山也很难分清的。 这天，齐老爷有点喝高了，想去留香院找小春，想起了儿子(老不正经！)，于是和书童(正扮演少爷)说: 今天你扮成我，你的事过几天我做主。 于是书童又穿上老爷的衣服，贴上胡子，还有模有样。 [ 装饰者模式: 川剧《变脸》 == 本体就是那个，但外表已经改变。 ]
扯淡又乱文终于再次出现了
1.骗子: 昨天(08.09.12)清晨我老爸接到一个加急电话，XX老师称本人英勇地和一辆巨型卡车进行冲撞，结果重伤入院; ── 于是还在和周公下棋的我被手机吵醒，是紧张的老爸;── ‘是的，我没事！’ 鄙人近来紧持锻炼身体，但还不至于疯到和擎天柱较劲。 ─ _ _ ─ > 我家里的电话只在班级通讯录中才有留，难道学校数据库泄漏？ 事实上我对它觊觎已久。 鄙视那些利用情亲骗取他人钱财的勒涩、垃圾、败类！
2.红尘之网络: 我住的红尘公寓网络条件越来越差了，电信竟然还搞用户名+密码+登录软件加密; 猴子下了个破解软件，搞定。之后就是现在的情况 ── 不定时断线。还好我早就戒了游戏，不然那可是悲愤的怒吼…… (这篇文章能不能发，就看天意了)
状态模式： 允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。 ——> 策略模式: 由客户主动指定context对象所要组合的策略对象是哪一个。
把各个状态分别继承于状态接口， 并得到上下文类对象;
在上下文类中，所有的状态都在构造器（主类）中创建并赋值, 配合函数处理状态（调用状态对象）;
当前状态在状态对象集合中游走改变，以反应出context内部的状态，因此，context的行为也会跟着改变。（由上下文类和当前状态决定之后状态）
迭代器模式： 提供一种方法顺序访问一个聚合对象中的各个元素(不必在意其数据结构)，而不是暴露其内部的表示。（适配器？？相似，一个聚合对象，一个连接多个类）
组合模式： 允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。（叶子节点、组合节点！有点头晕，回想起当年C++时的无穷指针恐惧症）
设计原则： 一个类应该只有一个引起变化的原因。── 内聚
模板方法模式： 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。（使用方法把算法定义成一组步骤，让后让子类实现步骤）hook(钩子)： 在超类中默认不做任何事，子类可以视情况决定是不是覆盖他们。[当子类 '必须' 提供算法中某个方法和步骤的实现时，使用抽象方法。 如果算法的这个部分是可选的，就使用钩子。]
OO 设计原则好莱坞原则： 别调用(打电话给)我们{高层组件}，我们会调用(打电话给)你{低层组件}。(将决策权交给高层模块)
模板很常用，记得学《面向对象》那门课时，举的例子大部分就是模板方法; hook的概念也常听说甚至使用过，如今终于明了; 看看几个设计模式的区别：
模板模式 ── 子类决定如何实现算法中的某些步骤;
策略 ── 封装可互换的行为，然后使用委托来决定要采用哪一个行为;
工厂方法 ── 由子类决定实例化那个具体类;
适配器模式： 将一个类的接口，转换成客户期望的另一个接口。适配器让原来接口不兼容的类可以合作无间。
适配器模式过程（客户无须知道被适配者接口是什么，而被适配者接口无须修改）：
客户通过目标接口调用适配器的方法对适配器发出请求;
适配器使用被适配者接口把请求转换成被失陪者的一个或多个调用接口;
客户接受收到调用的结果，但并未察觉这一切是适配器在起转换作用。
写在适配器之后： 适配器就由于并口转串口线，听起来很牛X，实际上辛辛苦苦只有自己知道。 在取舍之间，适配器连接不同接口之间。书中实例，老母鸡装土鸭，鸳鸯披上公鸡外衣。不同于装饰者，适配器负责转换，而不是继承。
