（本文于2010.10.01发表在《草根》杂志第四期,LAMP交流超级群（500人）：106382633）
PHP由Sapi、Main、Zend和Ext组成，PHP应用由哪些组成？地基+上层建筑。所谓地基就是各个应用间共有的那些部分，像现在流行的很多PHP框架就是试图给你打个地基。我不大喜欢别人给我打地基，所以平时都是自己打地基，自己打的地基牢与不牢自己最清楚。我爸是个建筑家，他建房子的能力在我们小镇也是赫赫有名了，从小耳濡目染，导致我也对打地基搞建筑很感兴趣，现在把这股劲弄到打软件地基上来，看能打出个啥地基出来，嘿嘿。
这个地基应该怎么打？说实话这非常依赖经验。纯理论派的家伙，别看他口若悬河讲起理论来滔滔不绝，你一让他给你写一个出来看看，他立马消失；纯实战派的家伙怎么样，对比想象一下便知，在此不在废话。我不喜欢蛮干，所以我推崇的是中庸之道：理论与实践相结合。
看过一堆框架后相信很多人多少都对什么控制器、视图、模型之类的东西有点熟悉了，在此也不多说。我想说的是，把眼光放远一点，放灵活一点，放实际一点。又远又实际？这不是矛盾么？那可未必。面向对象是不是较新的开发方式？看着那么多粉丝前扑后继“奔向”软件开发的“真理”，我倒开始打退堂鼓。当然，你可以认为我面向对象能力不过关：）然而翻开《人月神话》，感受一下真正的大师对面向对象开发方式的淡然的态度，我忽然觉得以前对面向对象开发的狂热是多么幼稚……
实际上我想说的是，面向对象不过是一种普通的软件开发方式，而且它的名字取得很莫名其妙，什么是“面向”对象？为什么是“面向”而不是“背向”？这很滑稽，所以我宁愿称之为“对象化”编程，以跟“结构化”编程相对应。对象又多少种呢？在PHP里，基础设施大部分是地基对象。注意，我说的是“对象”，而不是“类”。我很反感讨论对象时把类扯进来。PHP程序的一次运行就像一个士兵到一个城堡内送一封信，得到城主的处理后把结果送回，从进城门到出城门这一过程就是PHP脚本的执行过程。它的本质就是“过程”，不认识这个本质的设计注定是失败的。这个过程你会怎么设计？这就跟打基础一样啦。你会想，可能会有两个士兵守城门，进了城门后有向导，向导会问你有什么事，然后告诉你怎么走，走到目的地后又有士兵拦住你要证明，通过证明后才让你进入办事处，然后才是实际的事务，完成事务后一路返回，向各个守卫告别，最后离开城门：整个过程就是PHP脚本的执行过程。
发觉我经常走题万里，看，什么是灵活一点什么是实际一点，怎么打地基，都跑九霄云外去了，抱歉抱歉。实际上灵活、实际等概念跟其它众多优秀设计理念完全是融合在一起的，不好单独抽出来说明而不涉及其它概念，但基于这些互相融合的概念，设计出来的系统却是非常灵活的系统，具有非常低的互相纠缠关系，用术语说，是“耦合”关系。“零件”是极富表现力的隐喻，一个系统的动作都是由零件组织起来的。OK，回到城堡的例子，前面说的守卫啊，向导啊就是各种各样的零件。零件需要“类”吗？直接来看，不需要，它们各成自的职责，管它什么类不类。当你真正需要具有相 同职责的多个零件时，你才真正需要类。我认为就php的执行模式来看，它应该添加一个编程元素：对象，然后赋给它各种修饰，如抽象对象 啦，抽象接口啦，等等。偏偏PHP那班开发人员死脑筋，一味只知道照搬其它语言的概念，对“建设有PHP特色的编程模式”没有冲劲。
好了，不再瞎扯了：）回到城堡上来。刚进门需要一个人接待你，不管你要什么，你总是要进门的嘛，所以初始检查就是这个守卫的责任了，放在PHP里，就是所谓的index.php，所有的请求统一由它来接收。这个守卫要做些什么，有哪些职责，都需要你这个设计师来设计。如果这个人不符合进门标准，那么不好意思，只能请你回去了，呵呵。如果通过了检查，守卫可能要根据你的要求来选择为你服务的后续人员，比如你只认识英文，那我当然要给你布置英文环境了，呵呵。向导又做什么呢，它要根据你想去的目的地为你指路，所以它需要知道你的目的地，和一张城堡地图。如果在城堡地图里找不到你要去的地方，那么sorry，您来错地方了，地图是一件公有物品，因为如果有谁要告诉这个卫兵另一个目的地的话，它都必须是在地图里明确标明的一个地方。对比到PHP里，你很容易就能知道这是一个dispatch+route的过程，呵呵。所以开发这些名词的那些家伙也只是借了些隐喻而已，没什么大不了的，只要你想象力丰富，你完全可以颠倒这个一般的城堡规则，按你的意思来构建属于你的城堡规则。
指令操作数据这种方式，跟数据本身具有绑定的指令这种方式，有什么本质的区别？没有质的区别。你可能会跟我说在认知上有区别，对，但这种区别我认为并没有想象中的那么大，只是把主动权倒了一下而已，并没有多少神奇的能力和效果。面向对象编程实在是被吹得太过了。
不觉得？再看看《领域驱动设计》里的服务。你觉得服务操作实体是不是跟指令操作数据非常相像？这是一个非常大的讽刺，面向对象的终点，却是它们所不屑的“指令操作数据”的编程方式！呜呼，“面向对象技术并没有给我们带来‘神奇的效应’，不管开发商如何吹嘘面向对象OO(Object-Oriented)工具是多么万能，也不管那些OO狂热者是多么毅然地前赴后继，这方面的数据从20世纪80年代以来并没有发生大的改观”。
反观目前的PHP框架，有多少是遵循了软件设计和对象式编程的精髓呢？很遗憾，没有。Zend Framework？不客气地说，它连幼儿都算不上，还只是个婴儿，而且是个委员会产品，跟软件艺术相差几万光年。
我不喜欢在领域层乱搞对象，这样你只会给自己带来麻烦，你很难灵活地把它们保存到数据库中。虽然我不喜欢过早优化，但即便是不优化，对象映射到关系也是件很麻烦的事情，如果再需要为了性能进行数据库重构，引入各种不合关系数据原则的修改，则情况会更糟。软件开发的首要使命就是降低复杂度，对象关系映射却成功地把复杂度提高到了一个新的高度。当然你熟悉了ORM，小系统开发起来非常快，但不要把这套经验照搬到大负载系统里来，这样你会死得很惨。
再看看ROR，它现在已经为了迎合所谓的“企业级应用”而“成功地”变得越来越复杂，等着看它被彻底抛弃吧。
这个地基应该怎么打？说实话这非常依赖经验。纯理论派的家伙，别看他口若悬河讲起理论来滔滔不绝，你一让他给你写一个出来看看，他立马消失；纯实战派的家伙怎么样，对比想象一下便知，在此不在废话。我不喜欢蛮干，所以我推崇的是中庸之道：理论与实践相结合。
看过一堆框架后相信很多人多少都对什么控制器、视图、模型之类的东西有点熟悉了，在此也不多说。我想说的是，把眼光放远一点，放灵活一点，放实际一点。又远又实际？这不是矛盾么？那可未必。面向对象是不是较新的开发方式？看着那么多粉丝前扑后继“奔向”软件开发的“真理”，我倒开始打退堂鼓。当然，你可以认为我面向对象能力不过关：）然而翻开《人月神话》，感受一下真正的大师对面向对象开发方式的淡然的态度，我忽然觉得以前对面向对象开发的狂热是多么幼稚……
实际上我想说的是，面向对象不过是一种普通的软件开发方式，而且它的名字取得很莫名其妙，什么是“面向”对象？为什么是“面向”而不是“背向”？这很滑稽，所以我宁愿称之为“对象化”编程，以跟“结构化”编程相对应。对象又多少种呢？在PHP里，基础设施大部分是地基对象。注意，我说的是“对象”，而不是“类”。我很反感讨论对象时把类扯进来。PHP程序的一次运行就像一个士兵到一个城堡内送一封信，得到城主的处理后把结果送回，从进城门到出城门这一过程就是PHP脚本的执行过程。它的本质就是“过程”，不认识这个本质的设计注定是失败的。这个过程你会怎么设计？这就跟打基础一样啦。你会想，可能会有两个士兵守城门，进了城门后有向导，向导会问你有什么事，然后告诉你怎么走，走到目的地后又有士兵拦住你要证明，通过证明后才让你进入办事处，然后才是实际的事务，完成事务后一路返回，向各个守卫告别，最后离开城门：整个过程就是PHP脚本的执行过程。
发觉我经常走题万里，看，什么是灵活一点什么是实际一点，怎么打地基，都跑九霄云外去了，抱歉抱歉。实际上灵活、实际等概念跟其它众多优秀设计理念完全是融合在一起的，不好单独抽出来说明而不涉及其它概念，但基于这些互相融合的概念，设计出来的系统却是非常灵活的系统，具有非常低的互相纠缠关系，用术语说，是“耦合”关系。“零件”是极富表现力的隐喻，一个系统的动作都是由零件组织起来的。OK，回到城堡的例子，前面说的守卫啊，向导啊就是各种各样的零件。零件需要“类”吗？直接来看，不需要，它们各成自的职责，管它什么类不类。当你真正需要具有相 同职责的多个零件时，你才真正需要类。我认为就php的执行模式来看，它应该添加一个编程元素：对象，然后赋给它各种修饰，如抽象对象 啦，抽象接口啦，等等。偏偏PHP那班开发人员死脑筋，一味只知道照搬其它语言的概念，对“建设有PHP特色的编程模式”没有冲劲。
好了，不再瞎扯了：）回到城堡上来。刚进门需要一个人接待你，不管你要什么，你总是要进门的嘛，所以初始检查就是这个守卫的责任了，放在PHP里，就是所谓的index.php，所有的请求统一由它来接收。这个守卫要做些什么，有哪些职责，都需要你这个设计师来设计。如果这个人不符合进门标准，那么不好意思，只能请你回去了，呵呵。如果通过了检查，守卫可能要根据你的要求来选择为你服务的后续人员，比如你只认识英文，那我当然要给你布置英文环境了，呵呵。向导又做什么呢，它要根据你想去的目的地为你指路，所以它需要知道你的目的地，和一张城堡地图。如果在城堡地图里找不到你要去的地方，那么sorry，您来错地方了，地图是一件公有物品，因为如果有谁要告诉这个卫兵另一个目的地的话，它都必须是在地图里明确标明的一个地方。对比到PHP里，你很容易就能知道这是一个dispatch+route的过程，呵呵。所以开发这些名词的那些家伙也只是借了些隐喻而已，没什么大不了的，只要你想象力丰富，你完全可以颠倒这个一般的城堡规则，按你的意思来构建属于你的城堡规则。
指令操作数据这种方式，跟数据本身具有绑定的指令这种方式，有什么本质的区别？没有质的区别。你可能会跟我说在认知上有区别，对，但这种区别我认为并没有想象中的那么大，只是把主动权倒了一下而已，并没有多少神奇的能力和效果。面向对象编程实在是被吹得太过了。
不觉得？再看看《领域驱动设计》里的服务。你觉得服务操作实体是不是跟指令操作数据非常相像？这是一个非常大的讽刺，面向对象的终点，却是它们所不屑的“指令操作数据”的编程方式！呜呼，“面向对象技术并没有给我们带来‘神奇的效应’，不管开发商如何吹嘘面向对象OO(Object-Oriented)工具是多么万能，也不管那些OO狂热者是多么毅然地前赴后继，这方面的数据从20世纪80年代以来并没有发生大的改观”。
反观目前的PHP框架，有多少是遵循了软件设计和对象式编程的精髓呢？很遗憾，没有。Zend Framework？不客气地说，它连幼儿都算不上，还只是个婴儿，而且是个委员会产品，跟软件艺术相差几万光年。
我不喜欢在领域层乱搞对象，这样你只会给自己带来麻烦，你很难灵活地把它们保存到数据库中。虽然我不喜欢过早优化，但即便是不优化，对象映射到关系也是件很麻烦的事情，如果再需要为了性能进行数据库重构，引入各种不合关系数据原则的修改，则情况会更糟。软件开发的首要使命就是降低复杂度，对象关系映射却成功地把复杂度提高到了一个新的高度。当然你熟悉了ORM，小系统开发起来非常快，但不要把这套经验照搬到大负载系统里来，这样你会死得很惨。
再看看ROR，它现在已经为了迎合所谓的“企业级应用”而“成功地”变得越来越复杂，等着看它被彻底抛弃吧。
扫一扫
2223
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
