先讲一个自己看到故事吧：
你可能会直接在Web页面上书写大量的代码，因为PHP本身就有这样的功能；你也可能会在文件中添加工具函数（如数据库访问代码），然后把文件放到页面上去，不知不觉中写出来的Web应用程序也可以正常运行。你很陶醉在这里面，因为你的站点看起来是那么的奇妙，站点运行良好，客户也很开心，站点的用户也愿意为之付费。
然而在开始一个新的开发阶段时，再去看看以前的代码，问题就出现了。现在你有了一个更大的开发团队、更多的用户和更充足的预算。在没有任何预警的情况下，事态开始恶化，就像你的项目中了毒一样。
新加入的程序员开始费力的去理解你的代码，尽管你看起来就是几分钟能搞定的事情，虽然代码有些绕。他将花费你难以想象的时间去成为一个合格的团队成员。
要做一个简单改变，你发现必须更新20多个页面。这样原本计划一条的内容，实际上却花费了3天。
一个程序员保存了他对某个文件的修改，而实际上你在以前对这个文件进行了大量的修改，于是你以前的修改全部作废。这个损失在3天内也没有被发现，因为你有本地的副本，你一直在自己的代码上工作。当你发现这个问题的时候，你又花费一条来理清这个文件的头绪，以便第三个程序来说使用它使能按兵不动。
由于站点受欢迎，访问量增加，因此你需要把代码迁移到新的服务器上去。因为你不想重写迁移到新服务器的所修改的代码，所以迁移过程必须暂停开发工作。
最后你开始第二个阶段，并且头一天半一切正常。在你就要下班离开办公室时出现了第一个bug报告，几分钟后客户打电话来投诉。他和第一个报告的bug很相似，但经过更详细的调查，你发现这是由另一个引起类似行为的bug。你开始回忆在本阶段开始时的简单修改导致对整个项目其余部分所做的大量修改。
这时你认识到有些修改还不彻底。可能出错的原因是有的在最初被忽略了，或是有问题的文件在合并的时候被覆盖了。你急忙的进行必要的修改来解决问题。你脚不沾地的忙于测试所做的修改，但只是简单的复制和粘贴，这样应该不会有什么问题吧？
第二天早上你到达办公室时发现，购物车模块儿一整晚都不能运行了。你最后一分钟的修改漏掉了一个引号，所以代码不能用了。自然，在你酣睡的时候，其它时区的顾客并没有在睡觉，他们本来是有可能在你的网店上消费的。你解决了问题，安抚了客户，并且集合队伍开始另一天的救火行动。
许多php项目就是这样由一个个的小项目慢慢变成了令人恐惧的怪兽，由于表现层中也包含应用程序逻辑，随着数据库查询、用户验证、表单处理等工作的进行代码从一个页面复制到另一个页面，重复现象很早就开始在代码中蔓延。每当改动这些代码块之一，那么代码块出现的每个地方都需要改动，否则就会出现bug。当然，面向对象的好处远远不只是便于维护代码，他所体现的面向对象的思想将一个体系分作很多的个体，这样来，别人只需要知道怎么调用你所写的类或对象，并不一定要去理解他是怎么去实现的，除此自外，所积累的类变多了，所体现的就不是开始的感觉很费时，反而是可以在多个页面都能使用类中的方法时效率得到提高。
但事物总是没有绝对的，过度的依赖OOP也会存在弊端，当若是想通往PHP中高级的道路（当然自己现在连初级也算不上，但我会为之努力），OOP定将是不可或缺的。
