《Java组件设计》 第二章 组件设计原则

2         组件设计原则

Java 阵营一直倡导开源，开源运动如火如荼展开，催生了无数组件。但是，坦率的讲，这些开源的组件中，能够直接拿过来，不做任何改造，就能用于商业软件构建，满足功能和性能的要求，这样的优秀组件不多见。因此，核心软件开发者时常面对的尴尬局面是：大量的开源资源，都不满足我的要求。

实际上，组件设计是软件设计开发最精髓所在，凝聚了数据结构、面向对象、设计模式、线程并发同步、操作系统等诸多领域的最核心技术，一直是设计开发领域彰显技术水准的最高领地。

一个组件，要想被广泛重用，满足不同系统的使用要求，就要求组件有足够的能力适应不同的应用场合，提供满足需要的功能，并表现出优秀的性能。因此，组件设计过程中，组件设计者要考虑的问题非常广泛而复杂，组件设计者需要具备的知识、技能和经验要求非常高，一般工作经验至少在 5 年以上才有可能涉足组件设计这个领域。这也就解释了，为什么优秀组件不多的原因了。

本章将对组件设计过程中要考虑的核心要素、设计中要遵循的核心原则进行总体阐述，使读者能从总体上掌握如何发现、评判、设计一个优秀的组件。

本章将对目前业界存在的诸多技术争论、误区进行澄清，让读者从所谓的“业界潮流”、教条、“黄金定律”中走出来，真正理解组件设计过程的核心原则。这些核心原则如下：

原则一、精准解决共性问题

原则二、无配置文件

原则三、与使用者概念一致

原则四、业务无关的中立性

原则五、对使用环境无依赖

原则六：单类设计和实现

下面来详细讲解每个核心原则。

2.1             组件定位：精准解决共性问题

组件的产生，来源于软件工程实践中，对重复、反复出现、普遍的、有相似性的问题进行分析，剥离掉各个问题的特性，抽取各个问题之间的共性，然后确定要设计一个或多个组件，这样就确定了组件要解决的问题，而这个问题必然是共性的问题，不能是个性、特例的问题。如果不是共性的问题，那么写完后的代码就只能在一种或有限的几种情况下才能被使用，这样就无法实现大规模复用。不能广泛的被复用，就不能叫组件。

因此，组件首先是业务驱动的，不是技术驱动的。不能因为我们有了新的技术，就想着要写几个新的组件。共性的业务问题，是组件的产生来源。

另外，即使确定了组件要解决的问题，组件还必须提供解决问题最合理、最有效的方式和方法。如果提供的方法不是最好的，那么也很难得到使用者的喜欢，最终也难以推广和复用。因此，组件设计上，必须提供解决问题的精准思路和方案。这是决定同类别的组件中，哪个组件能胜出的最主要原因。

一个组件提供的问题解决方法，是否最有效，主要评价原则如下：

1)     技术与业务对齐：技术结构和技术概念要与业务上的模型、概念保持一致，在组件对外暴露的接口上，最好不要引入新的技术术语和概念，这样的组件最吻合业务的需求，也最容易理解。技术与业务对齐，这是组件设计的第一位重要原则。

2)     技术方案的优势：这是结构设计、技术选型范畴内要考虑的问题。实现同一个功能，可以有很多不同的结构设计，也有很多不同的技术可以采用，优秀的组件，一定在技术方案上有明显的技术优势。

3)     接口简单：组件暴露出来供外界使用的接口，必须足够简单。在概念和模型层面上与业务保持一致，另外接口封装、抽象上要仔细推敲，保证接口提供给别人使用时，调用者足够简单的使用。

4)     功能强大：组件如果提供的功能太少，意味着能帮用户解决的问题比较少，因此这样的组件实用性大打折扣。如果组件的功能过多，就会让用户觉得这个组件非常臃肿和庞大，用户只用了其中一小部分功能，其它大部分功能都用不上或者很少用，这样用户要在一本厚厚的使用手册中，仔细寻找自己需要的部分，去除自己不需要的部分，这也算不上一个优秀的组件。因此，一个组件提供的功能，既要能满足多种场景下不同客户的需求，还要在不同的需求中进行取舍和合并，使提供的功能集不会超出客户实际使用需求太多。

本文出自 “expert” 博客，转载请与作者联系！