![](https://csdnimg.cn/release/download_crawler_static/4321178/bg8.jpg)
顾名思义,就是把功能分解开来。为什么呢?我们之所以很难达到重用目标就是因为我们编写的程序
经常处于一种好像是重复的功能,但又有轻微差别的状态中。我们很多时候就会经不住诱惑,用拷贝
粘贴再做少量修改的方式完成一个功能。这种行为在 XP 中是坚决不被允许的。XP 提倡"Once and
only once",目的就是为了杜绝这种拷贝修改的现象。为了做到这一点,我们通常要把功能分解到细
粒度。很多的设计思想都提倡小类,为的就是这个目的。
所以,我们的程序中的类和方法的数目就会大大增长,而每个类和方法的平均代码却会大大的下降。
可是,我们怎么知道这个度应该要如何把握呢,关于这个疑问,并没有明确的答案,要看个人的功力
和具体的要求,但是一般来说,我们可以用一个简单的动词短语来命名类或方法的,那就会是比较好
的分类方法。
我们使用功能分解的规则,有助于提高重用性,因为我们每个类和方法的精度都提高了。这是符合大
自然的原则的,我们研究自然的主要的一个方向就是将物质分解。我们的思路同样可以应用在软件开
发上。除了重用性,功能分解还能实现透明的目标,因为我们使用了功能分解的规则之后,每个类都
有自己的单独功能,这样,我们对一个类的研究就可以集中在这个类本身,而不用牵涉到过多的类。
根据实际情况决定不同类间的耦合度
虽然我们总是希望类间的耦合度比较低,但是我们必须客观的评价耦合度。系统之间不可能总是松耦
合的,那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢?简单的说,就是根据需求的稳
定性,来决定耦合的程度。对于稳定性高的需求,不容易发生变化的需求,我们完全可以把各类设计
成紧耦合的(我们虽然讨论类之间的耦合度,但其实功能块、模块、包之间的耦合度也是一样的),
因为这样可以提高效率,而且我们还可以使用一些更好的技术来提高效率或简化代码,例如 Java 中
的内部类技术。可是,如果需求极有可能变化,我们就需要充分的考虑类之间的耦合问题,我们可以
想出各种各样的办法来降低耦合程度,但是归纳起来,不外乎增加抽象的层次来隔离不同的类,这个
抽象层次可以是具体的类,也可以是接口,或是一组的类(例如 Beans)。我们可以借用 Java 中的
一句话来概括降低耦合度的思想:"针对接口编程,而不是针对实现编程。"
设计不同的耦合度有利于实现透明和延展。对于类的客户(调用者)来说,他不需要知道过多的细节
(实现),他只关心他感兴趣的(接口)。这样,目标类对客户来说就是一个黑盒子。如果接口是稳
定的,那么,实现再怎么扩展,对客户来说也不会有很大的影响。以前那种牵一发而动全身的问题完
全可以缓解甚至避免。
其实,我们仔细的观察 GOF 的 23 种设计模式,没有一种模式的思路不是从增加抽象层次入手来解
决问题的。同样,我们去观察 Java 源码的时候,我们也可以发现,Java 源码中存在着大量的抽象层
次,初看之下,它们什么都不干,但是它们对系统的设计起着重大的作用。