JAVA组件设计原则(二)原则一：精准解决共性问题(摘自《java组件设计》)

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

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

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

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

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

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

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

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

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