PHP面向对象之我见

张沫 发布于 2010/08/25 17:06
阅读 860
收藏 3
PHP


PHP面向对象之我见

 

PHPSapiMainZendExt组成,PHP应用由哪些组成?地基+上层建筑。所谓地基就是各个应用间共有的那些部分,像现在流行的很多PHP框架就是试图给你打个地基。我不大喜欢别人给我打地基,所以平时都是自己打地基,自己打的地基牢与不牢自己最清楚。我爸是个建筑家,他建房子的能力在我们小镇也是赫赫有名了,从小耳濡目染,导致我也对打地基搞建筑很感兴趣,现在把这股劲弄到打软件地基上来,看能打出个啥地基出来,嘿嘿。

本文摘自《草根》杂志第三期 -- http://www.lampbrother.net/grassroots/

这个地基应该怎么打?说实话这非常依赖经验。纯理论派的家伙,别看他口若悬河讲起理论来滔滔不绝,你一让他给你写一个出来看看,他立马消失;纯实战派的家伙怎么样,对比想象一下便知,在此不在废话。我不喜欢蛮干,所以我推崇的是中庸之道:理论与实践相结合。 

看过一堆框架后相信很多人多少都对什么控制器、视图、模型之类的东西有点熟悉了,在此也不多说。我想说的是,把眼光放远一点,放灵活一点,放实际一点。又远又实际?这不是矛盾么?那可未必。面向对象是不是较新的开发方式?看着那么多粉丝前扑后继奔向软件开发的真理,我倒开始打退堂鼓。当然,你可以认为我面向对象能力不过关:)然而翻开《人月神话》,感受一下真正的大师对面向对象开发方式的淡然的态度,我忽然觉得以前对面向对象开发的狂热是多么幼稚……

实际上我想说的是,面向对象不过是一种普通的软件开发方式,而且它的名字取得很莫名其妙,什么是面向对象?为什么是面向而不是背向?这很滑稽,所以我宁愿称之为对象化编程,以跟结构化编程相对应。对象又多少种呢?在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,它现在已经为了迎合所谓的企业级应用成功地变得越来越复杂,等着看它被彻底抛弃吧。

 

 

加载中
0
曾建凯
曾建凯

以為是原創,搜了一下,原來是轉載,轉載應該注明一下啊!

Ror利用Ruby語法的優點和其對WebApp完善的封裝,自成一套體系而讓世人眼前一亮。然而Ror的OO是否就做到極致呢?Ror的啟動腳本就不是OO封裝的,但這無礙其給開發人員使用OO的特性。那麼index.php又有什麼可詬病的呢,那都是每個語言按其自身特性驅動而已。

框架簡化了邏輯,統一了開發的行為模式,提供了單元測試的可能性。回頭看看早年的模板,這不是一種進步嗎?

採用MVC,首先是邏輯區域的分離,當然,有些人喜歡在一個或者若干個.php文件裏面管理那種一根筋的邏輯,我無話可說。可是,大量實踐證明,採用MVC以後,能讓各自部分的邏輯更加健壯、完善。尤其是MVC各自都可以深入到各自更深入的層次,C層面,可以再次抽象,定義出resouce封裝(ROR針對數據Model專設Resource其實真的將MVC本身弄得複雜了),V層面,除了實現layout和widget的細化以外,還可以考慮做一個半狀態機的模板編譯器,這樣能更好的為前臺人員服務。

OOP或MVC肯定有再次升級的可能性,所有事物都在不斷的升級和發展。但就PHP而言,他不具有包的概念,對於混入、閉包這些特性的支持仍不是很好,期望操持這門語言幹一些高級優雅的事情,成本會很高,除非你樂意自己寫點擴展。於是乎,採用OO是一個相對不錯的選擇。尤其5.3,增加了namespace的支持,對於代碼維護和升級,容易度大大提升。可是,又有多少人會去跟進php的新特性呢?

0
张沫
张沫

引用来自#2楼“曾建凯”的帖子

以為是原創,搜了一下,原來是轉載,轉載應該注明一下啊!

Ror利用Ruby語法的優點和其對WebApp完善的封裝,自成一套體系而讓世人眼前一亮。然而Ror的OO是否就做到極致呢?Ror的啟動腳本就不是OO封裝的,但這無礙其給開發人員使用OO的特性。那麼index.php又有什麼可詬病的呢,那都是每個語言按其自身特性驅動而已。

框架簡化了邏輯,統一了開發的行為模式,提供了單元測試的可能性。回頭看看早年的模板,這不是一種進步嗎?

採用MVC,首先是邏輯區域的分離,當然,有些人喜歡在一個或者若干個.php文件裏面管理那種一根筋的邏輯,我無話可說。可是,大量實踐證明,採用MVC以後,能讓各自部分的邏輯更加健壯、完善。尤其是MVC各自都可以深入到各自更深入的層次,C層面,可以再次抽象,定義出resouce封裝(ROR針對數據Model專設Resource其實真的將MVC本身弄得複雜了),V層面,除了實現layout和widget的細化以外,還可以考慮做一個半狀態機的模板編譯器,這樣能更好的為前臺人員服務。

OOP或MVC肯定有再次升級的可能性,所有事物都在不斷的升級和發展。但就PHP而言,他不具有包的概念,對於混入、閉包這些特性的支持仍不是很好,期望操持這門語言幹一些高級優雅的事情,成本會很高,除非你樂意自己寫點擴展。於是乎,採用OO是一個相對不錯的選擇。尤其5.3,增加了namespace的支持,對於代碼維護和升級,容易度大大提升。可是,又有多少人會去跟進php的新特性呢?

写明转载自《草根》了啊  呵呵

0
海潮
海潮

php 的发展很不错,学习起来也很快。对于习惯了C++的程序员是个不错的选择,而且,PHP的编写习惯比较像编程。

0
曾建凯
曾建凯

引用来自#3楼“取消诅咒”的帖子

引用来自#2楼“曾建凯”的帖子

以為是原創,搜了一下,原來是轉載,轉載應該注明一下啊!

Ror利用Ruby語法的優點和其對WebApp完善的封裝,自成一套體系而讓世人眼前一亮。然而Ror的OO是否就做到極致呢?Ror的啟動腳本就不是OO封裝的,但這無礙其給開發人員使用OO的特性。那麼index.php又有什麼可詬病的呢,那都是每個語言按其自身特性驅動而已。

框架簡化了邏輯,統一了開發的行為模式,提供了單元測試的可能性。回頭看看早年的模板,這不是一種進步嗎?

採用MVC,首先是邏輯區域的分離,當然,有些人喜歡在一個或者若干個.php文件裏面管理那種一根筋的邏輯,我無話可說。可是,大量實踐證明,採用MVC以後,能讓各自部分的邏輯更加健壯、完善。尤其是MVC各自都可以深入到各自更深入的層次,C層面,可以再次抽象,定義出resouce封裝(ROR針對數據Model專設Resource其實真的將MVC本身弄得複雜了),V層面,除了實現layout和widget的細化以外,還可以考慮做一個半狀態機的模板編譯器,這樣能更好的為前臺人員服務。

OOP或MVC肯定有再次升級的可能性,所有事物都在不斷的升級和發展。但就PHP而言,他不具有包的概念,對於混入、閉包這些特性的支持仍不是很好,期望操持這門語言幹一些高級優雅的事情,成本會很高,除非你樂意自己寫點擴展。於是乎,採用OO是一個相對不錯的選擇。尤其5.3,增加了namespace的支持,對於代碼維護和升級,容易度大大提升。可是,又有多少人會去跟進php的新特性呢?

写明转载自《草根》了啊  呵呵

哎呀呀,这么明显的字眼,我晕,我瞎了眼了,该死,该死。

0
张沫
张沫

引用来自#5楼“曾建凯”的帖子

引用来自#3楼“取消诅咒”的帖子

引用来自#2楼“曾建凯”的帖子

以為是原創,搜了一下,原來是轉載,轉載應該注明一下啊!

Ror利用Ruby語法的優點和其對WebApp完善的封裝,自成一套體系而讓世人眼前一亮。然而Ror的OO是否就做到極致呢?Ror的啟動腳本就不是OO封裝的,但這無礙其給開發人員使用OO的特性。那麼index.php又有什麼可詬病的呢,那都是每個語言按其自身特性驅動而已。

框架簡化了邏輯,統一了開發的行為模式,提供了單元測試的可能性。回頭看看早年的模板,這不是一種進步嗎?

採用MVC,首先是邏輯區域的分離,當然,有些人喜歡在一個或者若干個.php文件裏面管理那種一根筋的邏輯,我無話可說。可是,大量實踐證明,採用MVC以後,能讓各自部分的邏輯更加健壯、完善。尤其是MVC各自都可以深入到各自更深入的層次,C層面,可以再次抽象,定義出resouce封裝(ROR針對數據Model專設Resource其實真的將MVC本身弄得複雜了),V層面,除了實現layout和widget的細化以外,還可以考慮做一個半狀態機的模板編譯器,這樣能更好的為前臺人員服務。

OOP或MVC肯定有再次升級的可能性,所有事物都在不斷的升級和發展。但就PHP而言,他不具有包的概念,對於混入、閉包這些特性的支持仍不是很好,期望操持這門語言幹一些高級優雅的事情,成本會很高,除非你樂意自己寫點擴展。於是乎,採用OO是一個相對不錯的選擇。尤其5.3,增加了namespace的支持,對於代碼維護和升級,容易度大大提升。可是,又有多少人會去跟進php的新特性呢?

写明转载自《草根》了啊  呵呵

哎呀呀,这么明显的字眼,我晕,我瞎了眼了,该死,该死。

不至于 不至于 呵呵

0
野草
野草
没意思~讨论这些~有些是执着于开发速度、有些是执着程序性能~各走各的路比较好~各有所需~无需矛盾~
0
虚无
虚无

做面向对象的之于装配车间的;

做面向过程的之于零部件车间的;

返回顶部
顶部