说明下, 本文仅限于我个人的理解与感受, 如果有错误或者不好的地方, 欢迎指正.
可能对于多数前端工程师来说, 面向过程的编程模式依旧是够用的, 其实很多时候, 我自己写的代码也几乎都只是函数没有类. 但面向过程毕竟有它的局限性. 当完成一些庞大的东西, 或者逻辑复杂, 容易产生混乱的代码时, 面向过程的模式就不容易处理了.
当然, 其实说到底, 还是和代码书写者的状况有关系. 我相信, 一个足够优秀的前端工程师, 即使面向过程, 也能写出清晰, 明了, 正确的程序来. 或者说, 在他的这种面向过程的编程下, 已经埋入了很深的面向对象的思想. (另外, 一定要有new才是面向对象吗? 显然不是, 面向对象只是一种思想, 不拘泥于实现的方法.)
面向对象的编程, 很大的一个好处, 就是把程序员从混乱中解放出来, 让思路更清晰, 把注意力集中在一些需要攻克的技术细节, 而非整个系统复杂的内部交互. 当然, 由此带来的东西就更多了, 比如更高的编程效率, 更少的bug.
但, 如何设计一个程序面向对象的结构呢? 这个我想是面向对象的过程中最关键的一步了. 它直接决定了之后具体实现的难易程度, 这应该也是一个高水平的前端工程师需要具备的能力.
接下来举两个例子, 谈谈两种不同的面向对象编程.
1. Web 游戏
Web 游戏的实现过程中, 处理一些具体算法方面的问题, 整体控制也是个问题. 比如说一个简单的操作, 可能会引起复杂的反应, 这些反应可能是各个方面的, 如画面呈现, 内部变化等等. 当然用面向过程的模式也能解决, 但普通的面向过程或许不那么容易简单地解决. 或者即使解决了, 代码的可读性, 或可维护性或许会不那么好.
这个时候, 用几个对象来分别控制游戏的不同部分, 或者会比较容易实现. 比如, 可以分成score, game, operation, 分别表示游戏的得分, 主体和操作控制, 而game又可以继续细分成foreground, stage, background等等. 这样一来, 思路就顿时清晰了.
这里提到的面向对象, 有一个特点, 就是所有的对象都是单独的实例, 不过很多时候就是这样, 一个类出来就只用一次. 这个时候, 我通常这样写JS:
var object = new function () {
this.someMethod = function () { };
} ();
2. 多级菜单
作为前端工程师, 这个东西应该多少有接触过. 这个例子有很明显的两个对象, 菜单(包括子菜单)和菜单项目. 用面向对象来实现, 我们就只用关心菜单和菜单项目之间的关系, 只要把这两者的关系思考清楚, 就能很容易地避免一些令人伤心的bug, 或者实现难度问题.
function Menu() {
this.add = function (item) { };
}
function Item() {
this.childMenu = null;
}
显然, 这里的面向对象, 与之前提到的区别就在于, 我们会用到多个实例, 而且这些实例的数量很多时候是不确定的. 但是只要把握住它们的关系, 就能高效的完成代码, 并且规避一些面向过程容易遇到的bug. 同时, 这种模式可以配合事件编程, 效果更好.
上面提到了面向对象两种看似不同的实践, 但其本质是一样的, 只是一个注重整体的规划, 一个注重功能实现. 配合使用, 我想对整个实现来说, 会有很大的意义. 当然, 或许上面这两个例子还不足以让你感觉到面向对象的优越性, 可能是因为这两个例子还不够复杂, 也没有很大的实现难度. 毕竟合适的才是最好的, 根据需求选择适当的模式, 才是聪明人的选择.
当然, 在实际操作的过程中, 或许并不是那么容易把某些东西抽象出来, 或者可以抽象出来的东西很多, 取舍又是个问题. 这些就需要前端工程师的经验和思考了.
最后再提一下基于事件的编程.
拿一些UI特效为例吧, 比如某个窗口飞入飞出, 我们希望它在飞入的时候做什么, 飞出的时候做什么. 当然随便写写也好, 但可维护性和可扩展性或许就不那么好了. 特别是当这些窗口不止一个两个, 运动也相互独立的时候, 普通的写法就更吃力了. 而且最主要的是, 即使实现了, 也相当容易出bug. 不过最终, 面向对象是核心, 基于事件是翅膀, 没了对象, 事件又能有什么大作为呢?
希望这些想法能对不熟悉或者刚接触面向对象编程的同学有一点参考作用, 也欢迎交流和指正.
