Eclipse设计实现可重用的SWT构件

中getColumnText方法中的复杂的条件判断还存在疑惑。难道只能这样无止境的判断下去吗?为什么不能直接的操纵每一列的数据呢?对于简单的需求，示例的说法相对容易，这么简洁的代码，你都不需要加任何的注释，然而一旦面对现实世界中纷繁复杂的业务系统，你的代码势必会迅速的膨胀，例如，仅对这个具体的表格来说：

　　如果有些行的某些列要求显示特殊的图标，你不得不在EmployeeLabelProvider 的getColumnImage方法中重复大量的判断;

　　如果调整了列之间的顺序，所有判断的地方都需要重新修改;

　　如果需要为每个不同的列增加不同的编辑功能(如text，Combo，Dialog)，你也会增加很多相似的判断;

　　如果某些列被要求是可以被隐藏的…

　　如果希望给不同的列增加过滤显示的功能或者为某些列增加排序的功能…

　　如果某些特定的行或者列需要增加显示背景色…

　　如果某些行需要增加特定的右键菜单…

　　如果某些行可以打开特定的编辑器或者对话框…

　　好吧，这些事情是我们经常会遇见的，我打赌如果你就按部就班的把这些功能实现后你的ContentProvider和LabelProvider中的代码一定混乱不堪，经过岁月的洗礼和需求的频繁变更，我们的代码迅速膨胀，就像Martin Fowler所说，到处散发出“臭味”，有经验的读者一定在项目中见过长达数千行的ContentProvider和LabelProvider类，这些类是如此的庞大以致于后期的维护和修改变得异常的困难。

　　何况，如果系统中存在数十个这样的不同的复杂的table，尽管你可以通过快速的拷贝，粘贴，重命名和简单的重构在几天内完成数十个表的工作，然而面对需求的变化，事情就变得越发的复杂，你不得不每天在需求的变化中，重复的修改这些数不清的ContentProvider和LabelProvider，是谁让这个世界如此疯狂?我们一定经历过这样疯狂拷贝粘贴的年代，面对很多类似的表格，我们经常会重复的创建无数的table，给他们增加很多相似的功能，当你沾沾自喜的数着自己一天又编写了多少个Java类，创建了多少个表格的时候，你是否想过，为什么这些Java类看上去这样的相似，难道重复的拷贝相似的代码不能让你思考一些更好的办法吗?

　　是时候了，是时候我们重新开始，创建一个高度可重用的TreeTable构件了，这个构件还要具有很强的扩展能力。为什么要可重用?因为你会不止一次的用到它。为什么要扩展?因为它不一定完全满足你的需求。如果我们编写程序的时候时刻有这样的想法，我相信我们的程序一定会比以前提高很多，永远不要假定你的代码是封闭的，要时刻准备着被重用。

　　不要认为这样的想法是多余的，笔者对国内外多个大型业务系统有所接触(财务，税务，零售等)，发现这些系统无一例外的构建在领域通用的框架之上，这些框架面对特定领域的问题的集合，提供了快速构建和灵活扩展的能力，其框架的可重用性非常强，业务开发人员可以开发很少的代码来构建完整的领域业务系统(极端的例子表明，可以不用编写代码就能生成定制的业务系统)。这些框架绝对不是一开始就被构建出来的，而是在实现多个类似业务系统过程中，逐渐的演化形成的，这些可定制的框架为软件公司带来了滚滚的利润，也为开发人员带来了很大的成就感。对于普通的程序员，只要我们坚持用可重用的眼光思考问题，就能得到提升。

　　首先，从小处看，我们应当保持代码的纯净，不能任何冗余的代码，冗余的即可重用。拷贝粘贴之余，只要我们坚持重构，在代码级别，我们能保持最大的重用性。更为重要的是，在保持了可重用性的同时，我们还集中了变化点，使得代码的维护变得更为容易。

　　其次，组件级别(UI上称为构件)，只要用相似的功能，我们都能精简，将业务上或者技术上相似的功能封装成可重用的组