程序的运行环境及其设计

     当初看《设计模式》和《J2EE核心模式》时，跟大多数朋友一样，我也想着怎样去实现各种模式，怎么借鉴这些模式到
PHP中来。而当我有一天看到《J2EE核心模式》里的前端控制器是持久的时，我脑袋一震：我是不是被弄得阻抗不匹配了？
之后再回来看《设计模式》里的单件模式，再回想起当年写C程序时的经历，我跟我自己说，我是彻底犯傻了：写什么单件？
为什么写单件？它适合PHP的动作方式么？有必要么？对这些问题，我思考一番后，答案都是：否。
    沉浸久了，要适时地走出来看看。所谓当局者迷，旁观者清，一样的道理。是的，我学习设计模式，学习架构模式，因
为我想得到更好的设计。然而对PHP程序员来说，这里有一个非常隐蔽的陷阱：传统的设计模式和架构模式是从持久型应用
里提取出来的，其中的一部分不仅不适合PHP，反而会对PHP程序员产生很大的误导！
    聊聊单件。比如Unix系统中一个运行在后台的daemon程序，它监听一个套接口。程序里有一个前端控制器，负责请求的
统一接收，然后把控制委派到内部的某个对象。为了讲述方便，假设这某个对象把所有的事情都办完了，执行流返回了前端
控制器，然后前端控制器把结果内容发送回请求者。接下来，该前端控制器并没有就此消失，它还是存在于内存里，继续监
听下一个请求。
    再看看PHP脚本又是如何。首先当然你也可以弄一个index.php的脚本充当前端控制器，把它实现成单件模式。然后，同
样，它给另外一个对象委派执行，把执行结果送回客户端，不一样的地方出现了：脚本结束时该前端控制器也灰飞烟灭。如
此，还有什么把前端控制器实现成单件的必要？
    当然，换种视点，把PHP脚本的一次执行看成前面daemon进程的生命周期，这套理论可以适用。但必须提起的是，这种
相似性并不多。daemon进程里对象是持久存在的，而PHP脚本里的对象不是。能对比到daemon进程里的对象的，实际上是PHP
进程里的跨请求间持久的global级别的资源（PHP/Zend main，module global，等等）。
    这种差异很多人都不是第一次感受到，但也许你并没有觉得什么不妥。然而在我看来这就是一种很强烈的不协调，是一
种无视程序运行环境对程序设计的影响的行为，因为这是核心差别，需要大力加以强调，而不是放在角落里偶尔提起，更因
为这种差别直接影响PHP框架的设计！
    有点困了，暂时先聊这一点，没什么深度，只是给大家布个关注的余地。有空继续聊些深层次的 :)