PHP中的面向对象和面向过程

PHP中的面向对象和面向过程

本文针对的读者

本文针对希望了解PHP中有关面向对象与面向过程两种编程方式的读者，包括新手和老手。假设读者对PHP及类的使用有一定程度的熟悉。

简介

“真正的天才具有正确评价不确定的，有风险的和矛盾的信息的能力。--邱吉尔”

使用许多编程语言时，你通常只能使用面向对象或面向过程二者之一的编程方式。而在PHP中，你可以自由选择或混用。目前绝大多数PHP程序员使用面向过程的方式，因为解析WEB页面本身就非常“过程化”(从一个标签到另一个标签)。在HTML中嵌入过程处理代码是很直接自然的作法，所以PHP程序员通常使用这种方式。

如果你是刚接触PHP，用面向过程的风格来书写代码很可能是你唯一的选择。但是如果你经常上PHP论坛和新闻组的话，你应该会看到有关“对象”的文章。你也可能看到过如何书写面向对象的PHP代码的教程。或者你也可能下载过一些现成的类库，并尝试着去实例化其中的对象和使用类方法--尽管你可能没有真正理解这些类为什么可以工作，或者为什么需要使用面向对象的方法来实现功能。

应该使用“面向对象”的风格还是“面向过程”的风格？双方各有支持者。像“对象是低效的”或“对象非常棒”这样的议论也时有耳闻。本文不尝试轻易判定两种方法的哪种具有绝对的优势，而是要找出每种方法的优缺点。

以下是面向过程风格的代码示例：

<?php

print "Hello, world.";

?>

以下是面向对象风格的代码示例：

<?php

class helloWorld {

function myPrint() {

print "Hello, world.";

}

}

$myHelloWorld = new helloWorld();

$myHelloWorld->myPrint();

?>

如果你想了解一些“面向对象”的基本知识，请使用Google搜索，网络上有非常多精彩的文章。

谁像这样写代码？

为了理解为什么这个论题成为论坛上口水战的导火线，我们看一些每个阵营的比较极端的例子。我们看看“过程狂热”和“对象狂热”。看看他们的观点听起来是不是有点熟悉。

过程狂热

过程狂热曾在上课时被计算机教师批评，因为这种方法没有使用更加抽象的实现方式。而支持面向过程者的观点“它可以工作！”并不能提高其编程水平和档次。毕业后他们可能找到一个工作，写驱动程序，文件系统或其它的偏向底层的编程，他们的注意力集中于速度和代码的精炼。

“过程狂热”极端的例子是抵制对象，抵制抽象化。他们总在想着如何让程序运行起来更快，而不在乎别人是否能读懂他们的代码。他们常常把编程当成竞赛而不是团队活动。除了PHP外，他们最喜爱的编程语言是C和汇编。在PHP世界中他们可能会开发PECL模块，贡献出高效率的代码。

对象狂热

对象狂热者热衷于在任何时候使用面向对象的风格来书写代码。他们没有真正考虑过用这种方式是否会影响程序的执行效率。有时候让人觉得他们更享受抽象的设计概念而不是现实的代码。他们通常很可能是项目管理者或文档书写者。

对象狂热者指出，如果没有抽象的设计方法我们仍然在使用0和1进行编程。他们喜欢用伪码来描述问题。极端的例子是对象狂热者即使知道有时候会牺牲效率仍然使用对象。 除了PHP，他们最喜欢的语言是Java和Smalltalk。在PHP世界中，他们可能会开发PEAR模块，贡献文档化非常好，易于维护的代码。

不要偏激和讽刺

你知道为什么论坛上总是充斥着各种偏见吗？你的经验阅历，你对新事物的态度都可能是原因。作为程序员，我们需要时常注意这些偏见并以开放的心态去学习新事物。

你的编码倾向？

考虑一下当你书写PHP代码时有什么偏好或倾向。通常这些偏好是比较隐晦的。有时候你可能在每个项目中有着同样的偏好。我个人倾向于“优雅”，但我不想在此定义如何才是“优雅”的代码，那应当出现在另一篇文章里。但是，理论化的偏好不一定适合于实际项目—相反地，他们常常是一种偏见。

理论化的倾向

• 用最少行数的代码提供一个完整的解决方案

• 在问题层次上考虑问题

这听起来似乎很不错。但“代码行数最少”如何来衡量呢？要把代码注释算在内吗？ 我们是否要把每一行都串起来而只用分号来区分呢？大括号呢？ 很明显这种想法是错误的。

再解释一下什么是“问题层次”。这是否意味着在我们的方案中的每个概念都需要建立一个类？或者需要在每个独立的文件里保持问题的每个部分，并建立一个复杂的文件树来与现实中的问题相对应？就是这样的想法--为每个想法准备一个文件或类！

很明显这些概括极端化后变得可笑。但现实中存在更微妙的证明。是否常常会有程序员在团队合作时插入一行复杂的，强大的但没有注释的代码？这对于接手维护这些代码的人来说无疑是非常令人沮丧的事。 相反地，是否你的官僚的自以为是的上一级程序员常常“横冲直撞”般地，建立接口和类? 而那些接口和类不仅仅限制了负责实现的程序员，也限制了效率和灵活性，导致客户要求扩展程序时手足无措。 这些都是以上各种倾向的微妙的证明。

实际倾向

一个项目开始的时候，首先要寻求实际的编码目的和方向。这个项目的实现目标是什么？下面是可能是答案。

• 开发快，发布快

• 尽可能快地运行

• 易于维护，改进和扩展

• 发布一个API

第一、二个方向倾向于使用过程化的风格，而最后两个倾向于使用面向对象的风格。

什么时候某种方式更有效？

现在让我们试着评价每种方式在现实中的优势。

面向过程案例

有关PHP的面向过程化编程优势的一个基础性的论据是：PHP是一个解释性的语言--这意味着，不像其它的语言一样，它不会被编译成一个可执行的包，而是被解释并马上执行。它是一种脚本语言并存储于文本文件中(例外的，如果使用了Zend编译工具)。

另一个反对在PHP4及更低版本中使用面向对象方式进行编码的理由是：在PHP的早期版本中对象的功能并没有经过良好设计。就像Rasmus曾说过的：“那是事后才想起要增加的功能”。这意味着在PHP4及更早的版本中，对象的效率是个问题。但PHP5出来后，这种情形会有改观。

以下两个最流行的PHP程序--OsCommerce 和PhpMyAdmin.主要使用面向过程的编码方式。它们构建起来很快，运行起来也很快。两者都很自然地采用嵌入HTML的方法。

OsCommerce

OsCommerce实际上使用了很多对象，但绝大部分功能是通过“过程”来实现的。我曾经hack过OsCommerce，为其增添一些对于客户非常实用的自定义功能。这个过程是挺麻烦的，因为OsCommerce中的很多过程代码，没有使用模板化的系统，并且设计成多语言版，所以需要花一定的时间才能上手。但是它可以工作，事实上它已经很好地运行在数目众多的电子商务站点上了。OsCommerce同时提供了一个论坛和一个开发框架用来开发模块和插件。因此，现在已经有了很多其它开发者提供的实用的功能模块。

PhpMyAdmin

PhpMyAdmin直接使用的类只有一个：Mimer SQL Validator类，依赖于PEAR包中的Mail_Mime, Net_DIME 和 SOAP。这可能是考虑到开发的方便：利用现成的可以实现目的的代码。除此之外，一切都是面向过程的，HTML和PHP代码也是混杂在一起。

PhpMyAdmin是我几乎每天都要用到的一个工具，用来对少量的数据表进行不太复杂的处理。有时我甚至鼓励我的客户将它当作后端的管理工具来使用（当然我会限制他们的权限）。PhpMyAdmin的表现非常棒，也很快。有时我想在一些项目中扩展PhpMyAdmin作为后端的管理工具，利用它的一些新功能如数据查询语句书签可以很方便地展示给我的客户和编辑。随着每个新版本的推出，PhpMyAdmin越来越实用，功能越来越强大。

面向过程小结

以上两个使用面向过程风格的程序都有非常好的文档和代码注释。OsCommerce提供的开发框架可以增加维护性和扩展性。但是两者都没有提供API，不能扩展程序到另外的体系中。

如果你想把OsCommerce整合到一个帐单程序中，需要花费大量的时间和精力，就像扩展PhpMyAdmin成一个供客户使用的后端管理工具。不过从它们设计的目的来看，确实在各自的领域中都表现地很出色。

面向对象案例

支持面向对象风格者的观点都集中于扩展性和封装。仅仅用面向对象的方式来写代码不会为你的代码产生文档，但它可以鼓励你为之添加文档。并且，为了易于扩展，你可能会写一个API。 PHP5许诺让面向对象编程更加愉快。我开玩笑地将它称为PHP中的”Java 2”版本，因为它整合了Java中的许多特性，像接口，面向对象模型，try-catch语句等。但即使在对面向对象支持不力的PHP4中，仍然出现了许多出色的面向对象应用程序。

Smarty

Smarty用来构建带有复杂表单并基于模板的站点。最近，我写了一个可以完全换“皮肤”的在线考试系统—可以不用改变任何底层的代码和功能就可以将整个站点的外观界面和风格完全改变。为了让设计师可以易于设计新的界面，我设计了一个自定义的标签库作为Smarty标签库的扩展。可以像这样简单地插入：

[navigation horizontal separated by " | "]

在一个页面的顶端有分隔开的导航。 因为Smarty已经提供了非常强大的机制来表现变量中包含的数据，这是一个映射较复杂的Smarty标签到skin标签的简单过程。关于这个的更多信息请看：http://simplequiz.peakepro.com/

由于Smarty封装成一个类，并且它的方法都有很详尽的文档，使得使用模板的过程变得令人难以置信地易于扩展。同时，通过强制性地只能显式地传递你要使用的变量给Smarty模板的方法，Smarty也为PHP的环境变量提供了一个保护层。这种方法有助于在Smarty模板设计师和程序员间建立安全、可靠的工作关系。

FPDF

FPDF是一个非常优秀的工具。如果你被改来改去的pdflib的API所困惑，或者不愿为商业化的解决方案而交钱；或者由于共享主机的限制，无法使用扩展模块—请考虑使用这个免费的，纯PHP构建的PDF生成工具。

这个类有很好的文档，包括许多很好的例子来阐述如何在PDF中布局文本和图片。在上面提到的同一个在线学习站点我使用FPDF来动态生成PDF文件，使用true type字体和300dpi精度的图像。在PHP中实例化FPDF类并进行PDF操作并不会花费太多额外的时间，因为PDF本身就可能需要花费几分钟来下载。事实上，动态生成并传送一个PDF所花的时间不比当使用一个慢速的网络连接来传送静态PDF文件所花的时间多。这都是相对而言的。并且，由于FPDF是基于类的，他可以被扩展。事实上，有些类方法虽然存在但还没有完全实现，仅作为一个框架，这可以为你在子类中建立你自己的内容(如自定义的头尾元素)提供向导。

FPDF

FPDF是一个非常优秀的工具。如果你被改来改去的pdflib的API所困惑，或者不愿为商业化的解决方案而交钱；或者由于共享主机的限制，无法使用扩展模块—请考虑使用这个免费的，纯PHP构建的PDF生成工具。

这个类有很好的文档，包括许多很好的例子来阐述如何在PDF中布局文本和图片。在上面提到的同一个在线学习站点我使用FPDF来动态生成PDF文件，使用true type字体和300dpi精度的图像。在PHP中实例化FPDF类并进行PDF操作并不会花费太多额外的时间，因为PDF本身就可能需要花费几分钟来下载。事实上，动态生成并传送一个PDF所花的时间不比当使用一个慢速的网络连接来传送静态PDF文件所花的时间多。这都是相对而言的。并且，由于FPDF是基于类的，他可以被扩展。事实上，有些类方法虽然存在但还没有完全实现，仅作为一个框架，这可以为你在子类中建立你自己的内容(如自定义的头尾元素)提供向导。

面向对象小结

Smarty和FPDF都提供了带有良好文档的API来扩展主类。这说明了在类的内部组织方法和数据的必要性--有时同样的功能可以用函数和全局变量来完成，但这样不易于扩展。并且，使用对象对跟踪和保持PDF或HTML文档的风格非常有帮助，你可以将同样的数据用不同的格式来发布。Smarty和FPDF都是使用对象来建立灵活实用的类库的极好的例子。

为什么两种方式都是必需的？

回到我们充满热情的程序员身上，我们开始赞美他们：

• 我们欣赏Smarty和FPDF的实用性和扩展性

• 我们欣赏osCommerce和phpMyAdmin的运行速度和良好表现

这种欣赏还包括对PHP的一些基础开发。PECL和PEAR都收到了很多赞扬和批评。我想这两个项目为阐明面向过程和面向对象编程的区别提供了很好的例子。

PECl提供了PHP的扩展库，用C和面向过程的方式开发，注重速度和简洁精炼。通常，这些都是从已经存在的LGPL软件中移植而来，其中许多有趣的特性已经加入PHP。毕竟，PHP是用C写的。

PEAR则贡献了很多有趣的类如建立Excel表或改变DNS记录等。使用PEAR类库可以为你节约大量时间，甚至可以让你在不怎么熟悉PHP的情况进行开发—“我不理解但它能用！”。

总结

希望本文能加深你对两种编程方式的理解，并且更重要地—鼓励你在更具体的细节上进行探索。我希望你会有自己的想法，并在实际开发中检验你的项目开发倾向，总结出更多实际的案例，并不啬写些针对本文的评论。

总之，每种方式都有其优势的一面，纠缠于争论不如离开去写些实际的代码！