当前位置: 首页 > 图文教程 > 网络编程 > PHP > php中的面向对象和面向过程

PHP
工作笔记:配置MySQL为高可用集群 (1)
MySQL (C API)VC实例及代码下载 (1)(5)
MySQL (C API)VC实例及代码下载 (1)(4)
MySQL (C API)VC实例及代码下载 (1)(3)
MySQL (C API)VC实例及代码下载 (1)(2)
MySQL (C API)VC实例及代码下载 (1)
用JSP连接mysql数据库的方法 (1)(2)
用JSP连接mysql数据库的方法 (1)
MySQL数据库账户授权的相关管理解析 (1)(2)
MySQL数据库账户授权的相关管理解析 (1)
SAP MaxDB MySQL修补数据库严重漏洞
MySQL研发中心成立发布会会后访问整理 (1)(2)
MySQL研发中心成立发布会会后访问整理 (1)
MySQL中SQL-TEXT、DATE和SET数据类型
MySQL存在权限提升及安全限制绕过漏洞
MySQL 卸载的问题
windows下安装、卸载mysql服务
如何正确卸载MySQL
MySQL手册版本 5.0.20-MySQL优化(四) (1)(5)
MySQL手册版本 5.0.20-MySQL优化(四) (1)(4)

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


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 69 ::
收藏到网摘: n/a

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

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

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

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

以下是面向过程风格的代码示例:
[PHP]
<?php
print"Hello,world.";
?>


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

<?php
classhelloWorld{
functionmyPrint(){
print"Hello,world.";
}
}
$myHelloWorld=newhelloWorld();
$myHelloWorld->myPrint();
?>
[/PHP]
如果你想了解一些“面向对象”的基本知识,请使用Google搜索,网络上有非常多精彩的文章。

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

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

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

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

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

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

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

理论化的倾向
&#8226;用最少行数的代码提供一个完整的解决方案
&#8226;在问题层次上考虑问题

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

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

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