JAVA组件设计原则(三)原则二-六(摘自《java组件设计》)

组件设计：无配置文件

组件自己不要带任何配置文件，组件所依赖的各种库也不带任何配置文件。

这个原则极为重要！！！

如果一个组件，自己定义了配置文件，无论是XML，Properties，还是其他的文件类型，内部的格式都是组件设计者自己定义的。我们假设一个中等的项目，会使用10个组件，那么就会有10个配置文件，这些配置文件的格式各不相同。那么我们的软件安装手册、维护手册就要仔细描述这10个配置文件的结构，我们的实施维护人员就要学会如何配置这10个文件。如果项目再大，需要集成50个组件，那就需要50个配置文件，对手册编写人员和实施维护人员，这是怎样的灾难啊！

归纳起来，如果一个组件自己带配置文件，带来的不良影响主要有：

1)不同组件的配置文件格式不统一，开发者、手册编写人员、实施人员、维护人员要学习不同格式、不同结构、不同的配置方式，学习的成本大大增加；

2)同一个配置(比如数据库连接串，IP地址等)，由于各个组件的配置方式不同，则实施人员要在多个配置文件中进行配置，增加了工作量，又难于保证升级时全部更新一致；

3)如果后续发现更好的组件，要用其替换原有的组件，则新的组件的配置文件与原组件的配置文件不同，则即使这两个组件的功能一致，我们也必需要更新实施维护手册，实施维护人员又要重新学习。

因此，基于配置文件的组件，是非常不容易被集成的。一个应用，无论其使用多少个组件，应该始终只有一个配置文件，用于集中配置这个应用的所有参数。而每个组件，都是以接口或者类的方式提供配置函数，应用集中读取所有配置信息，然后通过组件的配置函数，将配置参数设置到组件上。这样，将从根本上解决组件集成过程由组件配置文件引起的各种问题。

与使用者概念一致

组件提供接口，给应用来使用。在接口上表现出的概念术语、使用方式都应用与使用者的概念术语、使用方式完全对应，也就是，技术和业务对齐。

组件设计者常犯的毛病是，组件暴露的接口，引入了新的技术术语，这些术语在使用者的概念体系中根本就不存在，因此使用者理解起来非常困难，造成极大的学习障碍。这些与使用者概念不一致的技术术语，突出表现在接口命名、类名、函数名、参数名、返回值的含义等。

从本质上讲，组件接口上暴露的与使用者不一致的概念，要么是这个概念本身就是错误的或不恰当的，其不应该存在，要么就是这是个内部实现的概念，不应该包括在接口上。

组件设计：业务无关的中立性

一个组件，要在不同应用、不同场景下都能广泛的重用，这是组件设计者必需要实现的目标。但一个组件的产生，往往来源于一个特定的项目、一个特定的业务场景，在实现业务和项目功能的时候，组件设计者意识到，这个功能部分可以进行抽取，形成一个可重用的组件。因此，这个抽取的过程，组件设计者务必把与当前这个项目、这个业务特有的部分剥离掉，保留一般的、共性的功能，并重新封装和调整接口，以满足通用的使用场景。这样，这个组件可以与业务无关，保持自己的中立性，后续可以在其它的应用中被重用。

如何识别那些是业务特性，那些是一般的共性，这需要依赖组件设计者多年的经验。

组件设计实现：对使用环境无依赖

组件的内部实现，是否可以对将来组件被使用的环境做些假设？比如，是在Servlet容器中运行，仅使用一个组件的实例，仅处理一个目录…….？

如果组件设计者对组件将来被使用的环境做了一些假设，认为这些条件必然被满足，那么组件的代码实现就会和这些假设条件相关。如果这些条件不成立，则组件无法被使用。比如，组件设计者认为，将来应用中一个组件的实例就能满足需要，因此组件就设计成了单实例。当一个特殊的应用出现，需要使用两个组件实例来处理不同的场景，发现组件已经被设计成单实例，无法满足应用的这种“特殊”需求。

这种需求，真的很特殊吗？

客观上讲，需求来自于具体的应用，来自客户的使用场景和要解决的问题。需求，是独立与设计与实现的，尤其是与组件的设计实现无关。组件设计者之所以认为这种需求很“特殊”，是因为这个需求超出了组件设计者原来所做的假设。根本上讲，组件设计者不应该对组件将来的使用环境做任何假设，这样组件的使用场合仅受限于组件的能力集，只有应用需要的功能在组件的能力集范围内，各种环境下的不同应用都可以使用这个组件。

这样，组件才可以被广泛复用。

组件设计实现：单类设计和实现

怎样的组件，才是一个优秀的组件？从组件使用者的角度，组件要简单，易于使用，并且功能强大。那么组件怎样才能简单，易于使用？

首先，前面讲过，组件提供出来的接口，要与使用者的概念完全一致，这样使用者就非常容易理解组件的各个类、各个接口、各个方法、各个参数，这样就会易于使用。

但组件怎么才能简单呢？

最简单的组件，就是一个类。

一个类，就会比两个类简单，两个类就会比四个类简单。这个道理显而易见，其核心精髓是面向对象的基本设计原则：高内聚、低耦合。要严格控制类的数量，逻辑相关度很高的，就不允许拆成多个类。不支持将来变化的部分，就不提供接口。

组件，作为可重用的软件，不会承载太多的功能，组件的规模不会很大。因此，最理想的情况，组件就是单独的一个类。组件使用者用起来，是极致的简单。

我们从网上下载开源的项目，打开源码一看，豁，好家伙，一大堆的类和接口，不写几十个、几百个类好象就显不出作者的水平。其实真有必要写那么的多的类吗？

高内聚，高内聚，单类组件，简单的极致！