玩积木的程序员

自从我学习程序设计开始，就不断地听到大家谈论面向对象。在最开始接触C++时，确实被它的OO特性迷住了，相比之前用过的C语言更加丰富多彩。想当初，经常因为写出了一个类而暗自自豪半天。

现在做程序员也有些年头了，回过头来看以前似乎领悟到的OO思想又有了一些新的感悟。

一、代码之外的对象

提起OO，大家都会想到class关键字。以前老师这么教的，平时自己也是这么用的。虽然有些语言中的表现不一样，但本质上都是差不多的。刚开始时，说OO是一种技术；后来说OO是一种潮流；再后来说OO是一种信仰；后来的后来说OO是一种思想，总之是越说越玄。
不过有一点却是肯定的，我们可以将OO思想用在不支持OO特性的语言中。比如说，学了C++的人去写C程序，很可能写出来的还是C++风格的。

进一步推理，OO思想可以在语言之外体现出来。

年初就开始做插件系统方面的东西，做到现在系统中的插件有好几百个。对于这样的系统来说，插件就相当于非插件系统中的对象。没有谁规定对象必须是 class创建出来的。在以前写的文章中，有朋友的评论说到，这种情况可以叫做“对象模型（Model）”,和我这里说的是一个意思。

插件分为代码和配置两个部分，代码实现插件的业务，配置文件处理插件特性和插件之间的交互关系。可以说，在插件系统中，代码加配置组成的那个东西也能叫做“对象”，也就是代码之外的对象。

当我们能将OO思想摆脱代码的局限时，那么就能拥有更加广阔的思考空间了。

二、组合优于继承

封装、继承、多态是面向对象的三大特性。对于插件来说，封装是能很好地表现出来，但对于继承和多态却非常难实现了。至少我现在还没有看到有人将插件做成支持继承的。

以前有人问我觉得面向对象的三个特性中哪一个最有意思。当时我回答是多态，因为它最灵活。多态是和继承绑定的，继承是一种强耦合，也就是说派生类和基类不 可解耦。在有些时候继承和多态能带来意想不到的好处，但更多时候我们需要用组合来代替继承，以此获得更大的灵活性，尤其是站在系统的层面。

比如说有两个模块功能非常接近，如果按照派生的思路，在这两个模块之上提出一个基类，继承两个子类来完成具体的功能。对于代码之中的对象这样做没什么问 题，但对于代码之外的对象，只能采用组合来代替派生的思路了。做法是将两个模块的公用部分做成一个公用子模块C，不同部分做成A、B两个模块。A与C组合 起来生成第一个模块，B与C组合起来生成第二个模块。
还有一种解决方法就是用配置来处理模块特性，大家可以参考我以前写过的文章。

在设计模式中也强调“组合优于继承”。

三、好积木的要点

将软件模块比作积木，我们程序员就是玩积木的人了。各种各样的类库和框架、加上形形色色的控件，都是我们玩的积木。在插件系统中，插件就是积木。本文的着重点是插件系统。

好的“积木”需要具备以下的几点：

1、可插拔性，动态加载
2、外观可调
3、显示位置可配置指定
4、统一的列表管理
5、元素之间可通讯

上面介绍一些基本的要点，也是插件系统需要解决的若干个问题。上面的这些问题在以前的文章中已经简单介绍过。解决上述问题的方法多种多样，很感谢那些和我分享自己解决方法的朋友们:)
在现在的项目中，最关键的一点就是“配置”，这就要求满足1、2、3点，而4、5点则是将插件组装成完整系统的必备因素。

四、什么是技术含量

粗略地可以将程序员分成两类：做积木、与玩积木的人。

做积木的人指的就是那些自己写控件、插件的人，玩积木的人指的就是将各种各样控件或插件组装成系统的人。在业界大多数人都会认可那些自己写控件的，对于“只会拖拖控件”的程序员则不屑一顾。

我们很难说做积木与玩积木的人哪一个水平高，因为需要的是两种不同的能力。做积木的人需要对底层计算机技术有深刻的了解，而玩积木的人则需要对业务、用户需求和整体框架有清楚的认识。两个层面的人都需要有优化的意识。

很多学生的眼中，技术含量指的就是学习系统底层知识，掌握计算机原理；但工作过一段时间，尤其是做行业软件的程序员则会有不同的看法，他们更加关注怎样来“玩积木”，同样是一门学问。这也就是设计模式在学生中很少有人知道，而算法等基础理论离职业化程序员越来越远的原因。

我们不能仅仅按照做积木和玩积木两种类型来区分技术含量，不同的工作对技术的侧重点不一样。不过在我看来，玩积木才是我真正想做的事情，也可以说是架构设计了。当然，成为一个优秀的架构师还是相当困难的。 

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1504171