人类社会就是朝着越来越懒的方向发展的，可以只做一次的事情，就懒的做第二次；可以坐着去某处，就懒的走着去；无论是计算机的出现，还是软件行业的兴起，根本原因其实不是我们变懒了，而是我们变得学会偷懒了，其实偷懒也是一种艺术，也是能力的体现。
开发免不了写代码，相同的代码为了只写一次，我们搞出了方法定义；为了能够供他人使用，我们定义出了工具方法类。从C到各种高级语言的出现,再到各种框架，各种组件库，无一不意味着人们对于重复劳动的厌恶。
如果说模式的出现是针对一类问题的一个最优的解决办法，那么组件库的出现无疑是为了提高web应用前端开发的效率。无论是代码的简洁，还是使用的方便，都得到一个很大的提升。有的人会认为组件是个很神秘的东西，其实它无非是数据的一种展现形式，当你拥有一组数据，你可以选择多种形式来展现它，不管是下拉列表，表格，or树控件等。刨根问底是个好习惯，寻求最终的真相也不仅仅是福尔摩斯的兴趣，当然一切都得有个度。对于开发人员而言，如果遇到一个新技术，自己从来没有接触过的，那么在一定的范围内，我们必须要精通它，而不是简单的运用，你只有认识到了它的本质，你才有可能将它利用最大化，最优化。一句话，你才有可能写出最好的整合代码来衔接它。
我想很多人都做过各种各样的整合，自己的系统与第三方的系统，或者是集成一个功能，最简单无疑是使用第三方的一个jar包。当你做这些整合的时候，有没有这样的考虑？是在自己系统的任意需要使用到的地方直接调用jar中的方法，来达到目的；还是说先构思好一个小型的应用骨架，将对于这个jar包的应用整合在一个小范围内，亦或是直接一个中间类，我们的系统调用这个中间类，由中间类封装调用第三方jar。模式中我们可以应用代理模式或者合成模式。这样做的好处：
1.我们的系统与第三方的jar之间是一种弱耦合关系，想拆除或者更新只需修改中间类即可，我们的框架无需改动
2.显然这样的改动符合java编码的原则之开---闭 原则：一个软件实体应当对扩展开放，对修改关闭。
3.更利于代码的阅读和维护，因为一切相关的功能都在中间类，不会杂乱在系统中，调用关系一目了然。
4.更高的代码复用率，相同的代码在整个系统中只会出现一次。
其实这就是接口隔离思想的一种体现。
web应用前端组件中最难写最常用的一个组件应该是树控件了，当你实现一个树控件的时候，有没有考虑一下上面提到的方法？如果考虑到了，一般应该怎样来实现呢。
1.首先，确定一个中间类，这里我们把它叫做树模型：TreeModel
2.确定这个类的职责：加载树，组装树节点。在实现一个具体类之前先明确这个类的职责，可以有效地让我们避免数据泥团等问题的出现
3.考虑各种应用场景，各种树控件的具体实现，抽离出树控件实现的公共代码
4.明确树控件与业务系统之间耦合的面，我们会发现当把一切剥离之后，树控件与业务系统之间的交互，仅仅是获取一些展示所需用的数据而已
5.明确本质之后，将获取数据的操作封装成接口，利用接口隔离组件库与业务系统之间的耦合
6.当主干TreeModel实现完毕后,我们可以考虑一些细枝末节。比如节点点击事件等，这些都可以做成接口，由模型持有引用即可。
最终我们的业务系统只跟这个TreeModel相耦合，这样我们调试问题，阅读代码，或者是替换控件库，都一样不会太难。