最近比较忙，奇怪的是越忙的时候就越会有一些很无聊的胡思乱想。想到了一个初学面向对象时被问到烂了的问题：封装到底是什么。这个问题课本有标准答案式的解答，什么隐藏内部实现保留外部接口，但我并不满意这个回答。今天上课的时候又被老师的关联话题提起，于是想记录一下我现在的想法。

说来惭愧，听说 控制反转（Inversion of Control） 和 依赖注入（Dependency Injection） 这两个名词已经是大二的事情了，时至今日才想明白了具体的含义。我之前知道依赖注入的用法，一直将控制反转将其等同化，现在看来二者其实还是存在差别的。于是今天就此也顺便查阅了一些资料，将一些思考记录下来。

最近读《Ruby 设计模式》 [1] （第 n 次重读），对其中的一个观点特别认同：设计模式终将随着语言抽象能力的强化而消失在代码中。正如作者曾经在 C 语言中用函数指针结构体管理操作特定结构体的“面向对象设计模式”，随着面向对象融入语言而消失。GoF 的设计模式很经典，但是在 Ruby、Python 等表达力强大的语言火热之后，部分原来可以称之为“模式”的做法已经开始有了融入语言的趋势。

虽然这篇博客讨论的是命令模式，但我不会再絮叨一边命令模式是什么，已经有非常详细的资料 [2] 在先了。我想讨论的是关于在相对传统高级语言更“高级”的语言中，命令模式更佳的实现方式。这类语言包括但不限于：Python、Ruby、Scala、JavaScript。

策略模式（Strategy Pattern）来自四人帮的《设计模式：可复用面向对象软件的基础》一书。先看维基百科的描述：

• 维基中文站的词条“策略模式” [1]
• WIKIPEDIA(EN) Strategy Pattern [2]

而我对它的理解，是“隔离出**有多种选择的部分**”，就如工具箱里的多用螺丝刀——一把螺丝刀可以装上十字头、一字头甚至是锥子头。

最近读 Martin Folwer 的《企业应用架构模式》，其中对于关系型数据库与对象模型的同步问题，提到了使用 DataMapper 和工作单元来协调。

而关系型数据库的数据储存和对象模型的差异在于，关系型数据库是不允许集合类型存在的。在典型的 1 - N 关系模式中，是由 N 来保存对 1 的引用（数据库中体现为外键）；而在对象模型中， 1 - N 的聚集关系是由 1 来保存 N 的集合。也就是说，数据映射层的一个职责，是完成这个“翻转”过程。

话说这货是从 Martin 大神的《企业应用架构模式》中学到的，辅助 PHP 动态语言的特性，可以比 Java 轻松很多的实现延迟加载——通过一个虚代理占位符。唯一的缺陷，是只能代理对象，不能代理内置基本类型。

我试水的 PHP 领域模型设计中，也是用这个来实现 DomainObject 的延迟加载。