相关的设计模式有： Bridge、Composite、Decorator、Observer、Strategy等。

　　下面的例子演示了这个规则，它的前提是：我们对同一个数据结构，需要以任意的格式输出。

　　第一个例子，我们使用基于继承的框架，可以看到，它很难维护和扩展。

　　abstract class AbstractExampleDocument

　　{

　　// skip some code ...

　　public void output(Example structure)

　　{

　　if( null != structure )

　　{

　　this.format( structure );

　　}

　　}

　　protected void format(Example structure);

　　}

　　第二个例子，我们使用基于对象组合技术的框架，每个对象的任务都清楚的分离开来，我们可以替换、扩展格式类，而不用考虑其它的任何事情。

　　class DefaultExampleDocument

　　{

　　// skip some code ...

　　public void output(Example structure)

　　{

　　ExampleFormatter formatter =

　　(ExampleFormatter) manager.lookup(Roles.FORMATTER);

　　if( null != structure )

　　{

　　formatter.format(structure);

　　}

　　}

　　}

　　这里，用到了类似于"抽象工厂"的组件创建模式，它将组件的创建过程交给manager来完成;ExampleFormatter是所有格式的抽象父类;

　　将可变的部分和不可变的部分分离

　　"将可变的部分和不可变的部分分离"是面向对象设计的第三个原则。如果使用继承的复用技术，我们可以在抽象基类中定义好不可变的部分，而由其子类去具体实现可变的部分，不可变的部分不需要重复定义，而且便于维护。如果使用对象组合的复用技术，我们可以定义好不可变的部分，而可变的部分可以由不同的组件实现，根据需要，在运行时动态配置。这样，我们就有更多的时间关注可变的部分。

　　对于对象组合技术而言，每个组件只完成相对较小的功能，相互之间耦合比较松散，复用率较高，通过组合，就能获得新的功能。

　　减少方法的长度

　　通常，我们的方法应该只有尽量少的几行，太长的方法会难以理解，而且，如果方法太长，则应该重新设计。对此，可以总结为以下原则：

　　☆ 三十秒原则：如果另一个程序员无法在三十秒之内了解你的函数做了什么(What)，如何做(How)以及为什么要这样做(Why)，那就说明你的代码是难以维护的，必须得到提高;

　　☆ 一屏原则：如果一个函数的代码长度超过一个屏幕，那么或许这个函数太长了，应该拆分成更小的子函数;

　　☆ 一行代码尽量简短，并且保证一行代码只做一件事：那种看似技巧性的冗长代码只会增加代码维护的难度。

　　消除case / if语句

　　要尽量避免在代码中出现判断语句，来测试一个对象是否某个特定类的实例。通常，如果你需要这么做，那么，重新设计可能会有所帮助。我在工作中遇到这样的一个问题：我们在使用JAVA做XML解析时，对每个标签映射了一个JAVA类，采用SAX(简单的XML接口API：Simple API for XML)模型。结果，代码中反复出现了大量的判断语句，来测试当前的标签类型。为此，我们重新设计了DTD(文档类型定义：Document Type Definition)，为每个标签增加了一个固定的属性：classname，而且重新设计了每个标签映射的JAVA类的接口，统一了每个对象的操作：

　　addElement(Element aElement); //增加子元素

　　addAttribute(String attName, String attValue); //增加属性;

　　则彻底消除了所有的测试当前的标签类型的判断语句。每个对象通过 Class.forName(aElement.attributes.getAttribute("classname")).newInstence(); 动态创建，

　　减少参数个数

　　有大量参数需要传递的方法，通常很难阅读。我们可以将所有参数封装到一个对象中来完成对象的传递，这也有利于错误跟踪。

　　许多程序员因为，太多层的对象包装对系统效率有影响。是的，但是，和它带来的好处相比，我们宁愿做包装。毕竟，"封装"也是OO的基本特性之一，而且，"每个对象完成尽量少(而且简单)的功能"，也是OO的一个基本原则。

　　类层次的最高层应该是抽象类

　　在许多情况下，提供一个抽象基类有利做特性化扩展。由于在抽象基类中，大部分的功能和行为已经定义好，使我们更容易理解接口设计者的意图是什么。

　　由于JAVA不允许"多继承"，从一个抽象基类继承，就无法再从其它基类继承了。所以，提供一个抽象接口(interface)是个好主意，一个类可以实现多个接口，从而模拟实现了"多继承"，为类的设计提供了更大的灵活性。

　　尽量减少对变量的直接访问

　　对数据的封装原则应该规范化，不要把一个类的属性暴露给其它类，而是应该通过访问方法去保护他们，这有利于避免产生波纹效应。如果某个属性的名字改变，你只需要修改它的访问方法，而不是修改所有相关的代码。

　　子类应该特性化，完成特殊功能

　　如果一个子类只是使一个组件变成组件管理器，而不是实现接口功能，或者，重载某个功能，那么，就应该使用一个外部的容器类，而不是创建一个子类。

　　建议：类层次结构图，不要太深;