。
不要偏激和讽刺
你知道为什么论坛上总是充斥着各种偏见吗？你的经验阅历，你对新事物的态度都可能是原因。作为程序员，我们需要时常注意这些偏见并以开放的心态去学习新事物。
你的编码倾向？
考虑一下当你书写PHP代码时有什么偏好或倾向。通常这些偏好是比较隐晦的。有时候你可能在每个项目中有着同样的偏好。我个人倾向于“优雅”，但我不想在此定义如何才是“优雅”的代码，那应当出现在另一篇文章里。但是，理论化的偏好不一定适合于实际项目—相反地，他们常常是一种偏见。
理论化的倾向
• 用最少行数的代码提供一个完整的解决方案
• 在问题层次上考虑问题
这听起来似乎很不错。但“代码行数最少”如何来衡量呢？要把代码注释算在内吗？ 我们是否要把每一行都串起来而只用分号来区分呢？大括号呢？ 很明显这种想法是错误的。
再解释一下什么是“问题层次”。这是否意味着在我们的方案中的每个概念都需要建立一个类？或者需要在每个独立的文件里保持问题的每个部分，并建立一个复杂的文件树来与现实中的问题相对应？就是这样的想法--为每个想法准备一个文件或类！
很明显这些概括极端化后变得可笑。但现实中存在更微妙的证明。是否常常会有程序员在团队合作时插入一行复杂的，强大的但没有注释的代码？这对于接手维护这些代码的人来说无疑是非常令人沮丧的事。 相反地，是否你的官僚的自以为是的上一级程序员常常“横冲直撞”般地，建立接口和类? 而那些接口和类不仅仅限制了负责实现的程序员，也限制了效率和灵活性，导致客户要求扩展程序时手足无措。 这些都是以上各种倾向的微妙的证明。
实际倾向
一个项目开始的时候，首先要寻求实际的编码目的和方向。这个项目的实现目标是什么？下面是可能是答案。
• 开发快，发布快
• 尽可能快地运行
• 易于维护，改进和扩展
• 发布一个API
第一、二个方向倾向于使用过程化的风格，而最后两个倾向于使用面向对象的风格。
什么时候某种方式更有效？
现在让我们试着评价每种方式在现实中的优势。
面向过程案例
有关PHP的面向过程化编程优势的一个基础性的论据是：PHP是一个解释性的语言--这意味着，不像其它的语言一样，它不会被编译成一个可执行的包，而是被解释并马上执行。它是一种脚本语言并存储于文本文件中(例外的，如果使用了Zend编译工具)。
另一个反对在PHP4及更低版本中使用面向对象方式进行编码的理由是：在PHP的早期版本中对象的功能并没有经过良好设计。就像Rasmus曾说过的：“那是事后才想起要增加的功能”。这意味着在PHP4及更早的版本中，对象的效率是个问题。但PHP5出来后，这种情形会有改观。
以下两个最流行的PHP程序--OsCommerce 和PhpMyAdmin.主要使用面向过程的编码方式。它们构建起来很快，运行起来也很快。两者都很自然地采用嵌入HTML的方法。
OsCommerce
OsCommerce实际上使用了很多对象，但绝大部分功能是通过“过程”来实现的。我曾经hack过OsCommerce，为其增添一些对于客户非常实用的自定义功能。这个过程是挺麻烦的，因为OsCommerce中的很多过程代码，没有使用模板化的系统，并且设计成多语言版，所以需要花一定的时间才能上手。但是它可以工作，事实上它已经很好地运行在数目众多的电子商务站点上了。OsCommerce同时提供了一个论坛和一个开发框架用来开发模块和插件。因此，现在已经有了很多其它开发者提供的实用
不要偏激和讽刺
你知道为什么论坛上总是充斥着各种偏见吗？你的经验阅历，你对新事物的态度都可能是原因。作为程序员，我们需要时常注意这些偏见并以开放的心态去学习新事物。
你的编码倾向？
考虑一下当你书写PHP代码时有什么偏好或倾向。通常这些偏好是比较隐晦的。有时候你可能在每个项目中有着同样的偏好。我个人倾向于“优雅”，但我不想在此定义如何才是“优雅”的代码，那应当出现在另一篇文章里。但是，理论化的偏好不一定适合于实际项目—相反地，他们常常是一种偏见。
理论化的倾向
• 用最少行数的代码提供一个完整的解决方案
• 在问题层次上考虑问题
这听起来似乎很不错。但“代码行数最少”如何来衡量呢？要把代码注释算在内吗？ 我们是否要把每一行都串起来而只用分号来区分呢？大括号呢？ 很明显这种想法是错误的。
再解释一下什么是“问题层次”。这是否意味着在我们的方案中的每个概念都需要建立一个类？或者需要在每个独立的文件里保持问题的每个部分，并建立一个复杂的文件树来与现实中的问题相对应？就是这样的想法--为每个想法准备一个文件或类！
很明显这些概括极端化后变得可笑。但现实中存在更微妙的证明。是否常常会有程序员在团队合作时插入一行复杂的，强大的但没有注释的代码？这对于接手维护这些代码的人来说无疑是非常令人沮丧的事。 相反地，是否你的官僚的自以为是的上一级程序员常常“横冲直撞”般地，建立接口和类? 而那些接口和类不仅仅限制了负责实现的程序员，也限制了效率和灵活性，导致客户要求扩展程序时手足无措。 这些都是以上各种倾向的微妙的证明。
实际倾向
一个项目开始的时候，首先要寻求实际的编码目的和方向。这个项目的实现目标是什么？下面是可能是答案。
• 开发快，发布快
• 尽可能快地运行
• 易于维护，改进和扩展
• 发布一个API
第一、二个方向倾向于使用过程化的风格，而最后两个倾向于使用面向对象的风格。
什么时候某种方式更有效？
现在让我们试着评价每种方式在现实中的优势。
面向过程案例
有关PHP的面向过程化编程优势的一个基础性的论据是：PHP是一个解释性的语言--这意味着，不像其它的语言一样，它不会被编译成一个可执行的包，而是被解释并马上执行。它是一种脚本语言并存储于文本文件中(例外的，如果使用了Zend编译工具)。
另一个反对在PHP4及更低版本中使用面向对象方式进行编码的理由是：在PHP的早期版本中对象的功能并没有经过良好设计。就像Rasmus曾说过的：“那是事后才想起要增加的功能”。这意味着在PHP4及更早的版本中，对象的效率是个问题。但PHP5出来后，这种情形会有改观。
以下两个最流行的PHP程序--OsCommerce 和PhpMyAdmin.主要使用面向过程的编码方式。它们构建起来很快，运行起来也很快。两者都很自然地采用嵌入HTML的方法。
OsCommerce
OsCommerce实际上使用了很多对象，但绝大部分功能是通过“过程”来实现的。我曾经hack过OsCommerce，为其增添一些对于客户非常实用的自定义功能。这个过程是挺麻烦的，因为OsCommerce中的很多过程代码，没有使用模板化的系统，并且设计成多语言版，所以需要花一定的时间才能上手。但是它可以工作，事实上它已经很好地运行在数目众多的电子商务站点上了。OsCommerce同时提供了一个论坛和一个开发框架用来开发模块和插件。因此，现在已经有了很多其它开发者提供的实用
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
热门文章
