可以先看看代码对比，精华都在代码里：
基于类的方式改写：
http://git.oschina.net/web3d/DeCMF/commit/58f915b9d24ab5ffe40adf4ad4ed769fdb6ebe6e
原来的函数形式：
http://git.oschina.net/web3d/DeCMF/commit/228983fb76b7bd6b69e6116d984ebfe7454d4b8d
这个项目是为了演示OOP编程实践而建立的，基于OneThink CM框架。
上述代码，将一个函数的代码，拆分到两个类中-父子类继承，在后续整理的过程中，就发现了这样的好处，函数库中另一个类直接代码重用了。
get_addon_list函数的改写：
http://git.oschina.net/web3d/DeCMF/commit/9ae6a2fe9abe27789a1d1c0982d20f97950c1895
原本的一个get_list_field 函数58行，基于面向对象的方式初步改写后，变成240多行，咋一看，代码行数多了很多，不科学啊！
但仔细看后，除去注释90行、语句换行大致20行，其他嵌套语句拆分10几行，原本缺少的逻辑细化，并没有真正增加几行代码。
其实，OOP代码更多是个伪命题，我只是想以此为话题，回顾一下OOP！
面向对象好像对很多人不是个事，但其实只是大多数人没有真正去在意什么是OOP。
OOP的三大特性：
1.封装
把过程和数据包围起来，只让可信的类或者对象操作，对不可信的进行信息隐藏。
2.继承
通过过程抽象和数据抽象。理出一般与特殊的关系。代码重用。
3.多态
不同类的对象对同一消息作出响应的过程不同。接口重用！
将所有逻辑塞到一个函数或者类方法中是没有区别的，这不是面向对象，也不是面向对象的初衷，设计OOP的初衷是解决代码的重用问题。现实中代码的重用程度好像并没有一个明确的标准，所以不同的人实践后会有不同程度的接受度。
通过面向对象，我们要找到相关数据和功能逻辑的关系，并与外界相对隔离，专心专意的去解决一个问题，不会因为暴露出来的全局变量或者函数影响整体代码的可读性和可维护性；同时，考虑事物的多态性，分层去定义对象的属性与功能。
在团队项目中，一坨垃圾代码我们要维护很久很久，直到受不了离开为止。或者是新团队，从头开始写，用最牛掰的框架，最牛掰的架构，写出一坨垃圾代码，然后维护很久很久，直到受不了离开为止......
所以，能否战胜垃圾代码，其实才是真正检验程序员水平的标准。面试了很多人，也有一些新人加入团队后不久就离开，标准理由都是，项目太复杂了，代码太垃圾了，最好能从头开始一个新系统、或者给我一年时间重构现在的系统！
我只能不屑的一笑：你们都是懦夫，真正的程序员敢于直面垃圾的代码，敢于正视破碎的系统！
这是怎样的哀痛者和幸福者？然而造化又常常为平庸的程序员设计，以时间的流逝，来洗涤旧逻辑，仅使留下苍白的产品和微漠的悲哀。在这苍白的产品和微漠的悲哀中，又给程序员暂得偷生，维持着这似是而非的系统。你不知道这样的系统何时是一个尽头！
但我知道！OOP是没有尽头的！