整理一下两个月的收获和问题，说的不全，完全以这段时间的实践为主线。

一 面向对象 VS 面向过程
1.我们的选择
项目开始时，技术经理那边决定使用面向过程作为我们的主要开发方式，当时主要的考虑点是效率和项目人员对OO和面向过程的熟悉程度。
我们的项目是一个交易平台，预计并发、高负载、快速响应会是项目最重要的问题，再结合PHP本身的特点，我们觉得面向过程应该是我们的更好选择。
另外，项目中，除了我本人接触的OO较多外，其他人对于OO的理解还仅仅位于“对象”上， 对OOA/OOD/Design Pattern等基本无概念，而由于我们的时间和现有资源的问题，我们也不可能进行这方面的入职培训。 所以最终我们决定使用面向过程。

2.如何选择
很多人大谈OO或者面向过程的好处，互相攻击对方的方法缺陷。就讨论本身而言，辩论有利于更好的交流以及对知识更深层次的理解。但也容易带来一些偏见，这些往往是由于个人的阅历经验、对新事物的心态以及是否辩证看待事物有关。每个人的工作环境、项目要求等等都不尽相同，而OO和面向过程都不是万能的解决方案，他们有各自的优缺点，有各自的适应环境（所以不能一概而论， 不能断定哪种方式绝对的好），同时也有重叠的部分（既然有重叠，那么在某些情况下使用OO和面向过程皆可，具体使用哪一种，主要取决于个人的偏好）。
因而我们讨论两种方法，重点在于分析他们各自的利弊、适应环境，而不是打败对方。我们的目的在于赢得真理， 而不是赢得讨论。无论枪有多好，刀也不会淘汰；同时枪也的确比刀强大很多—某些情况下。
以下我的一些粗浅的个人理解，用于快速的判断实际应该如何选择。限于经验和个人水平，如有不妥甚至错误的地方，欢迎指出来。
* 面向对象有利于直接将现实中的“对象”移植过来，而面向过程则有利于直接应用我们生活中最常见的“过程式”思想。但是希望大家明白，现实世界并非完全“对象”，也并非完全的“过程”。当你的项目比较简单，业务逻辑也比较简单的情况下，面向过程可能是更加快速的选择，因为在这种情况下，你不必考虑太多的类设计，简单的“一步步来”即可。如果你的业务逻辑相当的复杂，在很多地方可能会大量的重用某些逻辑处理，你们的团队相当的庞大，你们需要紧密的合作等等，此时OO的优势将会非常明显。
* 项目要求和项目环境。如果你的PHP版本过低（如PHP4甚至PHP3），由于语言本身对面向对象的支持不够好，某些本来是面向对象的优点也会变成缺点，同时很多面向对象的特性也不能应用，这个时候再坚持OO就不是个好的选择了。 或者更干脆你用的是想C语言这样的完全不支持OO的编程语言，那么什么也别想了 —–  你想煮饭，首先得要有米才行。
* 应用某方式的成本。就像我们的团队一样，并非每个人都能理解OO，即使理解，理解程度也不尽相同，这可能会为大家的合作、项目的维护等带来不便。所以很多公司都有入职培训，不管你水平如何，大家一起培训，争取将大家调整到一个相近的水平线上。这需要时间、资金以及人力的投入，有时候最优的技术选择并不见得是最好的选择。
这里只能简单的列出几点判断要点，详细说的话，几本书也说不完，欢迎大家继续和我交流论坛。

PHP面向过程项目的一些细节
模板
对于一个稍有规模的网站（如何判断是没有标准的），页面显示和业务逻辑分离是一个非常重要的问题，可以说它在一定程度上决定了我们的项目的工作效率。对于很多程序员来说，编写程序的同时还要处理HTML，css，js等是一个嫉妒可怕的噩梦。可悲的是，目前为止并没有一种很好的解决方案能使得PHP程序员完全摆脱这种局面；可喜的是，我们已经有比较折中的方案：模板。
模板可以说是无数PHP程序员甚至是美工的救世主，它很方便的分离了页面显示和业务逻辑 —- 当然它不可能完全分离的开来，不过总归是比之前好太多了。比较有名如Smarty，PHPLib Template等等，前者属于编译型，后者则属解释型，各有优点，有兴趣可以搜索下。

  在我们的项目中，网站有公共的头部和尾部，准确的来说，有两个公共的头部和一个尾部，如果头部和尾部都唯一的话相对来说就简单一些了。
还是考虑到我们的网站对性能上的要求，我们决定不采用任何模板技术，或者说我们决定采用内嵌PHP代码方式的模板。大家先来看下面的代码：
 

Smarty方式：

<{foreach name=results from=$results item=result}>

<b><{$result.name}></b>

<b><{$result.id}></b>

<{/foreach}>

使用HereDoc：

<!–

EOT;

foreach($results as $value){print<<<EOT

–>

<b>{$value['name']}</b>

<b>{$value['id']}</b>

<!–

EOT;

}

–>嵌入html代码：

<?php

foreach($results as $value){

?>

<b><?php echo $value['name'];?></b>

<b><?php echo $value[id];?></b>

<?php

}

?>

上面的代码很简单，从一个表中取出用户列表，然后循环显示。代码一和代码二的功能实际上时一样的，不同的是代码1采用了模板（smarty语法），代码2采用了PHP原生语法（heredoc）。我们可以看到我们用原生的语法完成了模板所对应的功能，并且代码也同样的简单。可能有人说，smarty可以编译，可以缓存，有很多辅助函数，这些你通过简单的代码能够实现吗？
对于上面的问题，我的看法如下：
* 我认为smarty这种编译型模板提供的诸多额外函数做了过多的事情。在MVC模式下，这些函数所做的事情已经超出了V层的职责，会导致更换V层时，重复的编写一些代码，例如将V层从HTML换成WAP或者XML。当然这一点并不能使得我们做出放弃smarty的决定，因为项目不见得采用MVC模式开发，同时你也可以避免使用Smarty的某些函数。
* 几乎所有模板都使用自己的一套语法，学习代价高。smarty3已经使用PHP的原生语法了。
* 很多项目实时性要求相当高（我们的项目就是如此），采用编译型模板会导致数据不能及时显示，而且因为更新快，它的编译功能将变成鸡肋。而解释型模板由于不缓存结果（如果你给解释型模板提供缓存功能的话，那另当别论），每次请求都重新解释，效率不高、资源消耗相对较多。
*根据前面三点，我们发现PHP本身就能够完成我们要求的功能。

我的看法带有片面性，因为我主要是就着我当前的项目来讨论的。

对于模块下公共文件的重复利用的问题，我们使用ob系列的函数来替换即可，PHP中字符串替换的效率是相当高的（尽量不要用正则）。

纯粹的面向过程吗？
我们的项目属于大中型的项目，实际编码中发现有大量的重复代码，我们的业务逻辑相当的复杂（特别是在线支付模块），这个时候我们简单了考虑了一下便决定适当的使用一些对象（当然，这还称不上OO）。我们不是纯粹的面向对象狂热者，同样也不是面向过程狂热者，只有最合适的，没有最好的。

项目成功≠技术先进
其实这不属于面向过程的专属内容，它应该是超越开发方法的。不管你采用哪种方法开始，项目的完成才是最重要的，技术不能代表和决定一切，现实和理想总是有所相隔。代码可以重构，而项目可能没有机会进行第二次。大家要把握平衡点。