程序的运行环境及其设计

本文探讨了设计模式在PHP环境中的适用性,尤其是单例模式。作者指出,传统的设计模式多源自持久型应用,但在PHP的脚本环境中,某些模式可能并不适用,如单例模式在PHP的短生命周期中显得多余。文章通过比较Unix daemon程序与PHP脚本的运行方式,强调了理解程序运行环境对设计决策的重要性,特别是对PHP框架设计的影响。
     当初看《设计模式》和《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框架的设计!
    有点困了,暂时先聊这一点,没什么深度,只是给大家布个关注的余地。有空继续聊些深层次的 :)
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值