从上面的模型我们可以看出 Editor 类其实相当于一个 Facade，所有的界面与用户的交互都由它负责集中调度管理，Editor 会将装配行为分配给 EditorAssembler 类来处理，它还负责临时存储输入输出数据，当然如果我们有类似 transaction 或 session 之类的处理会由 Editor 委派到别的相关类去处理。应用 Facade 设计模式，我们可以给 Editor 改个名字叫 EditorFacade，这样更能体现设计者的意图，千万不要忽视类的命名，设计是一门严肃的科学，每一个细节我们都不能苟且，对架构的设计更要严谨。命名可以起到沟通的作用，还能起到提醒的功能，EditorFacade 提醒我们以后要给它添加新的行为是记住它是一个 Facade，不能将不相干的职责分配进来。

　　另外，我发现添加了 InputDataObject 类后，EditorComposite 就有两个职责：装载界面元素初始化数据(一些需要从环境中动态获得的输入数据，从 InputDataObject 对象中获得)和显示上一次编辑的数据(也从 InputDataObject 对象中获得)，我们定义两个方法来分别处理：loadDataInfo()-装载初始化数据;showPreInfo()-显示上一次编辑的数据。当然，一般来说这两个方法是私有的-private，因为这是 EditorComposite 自身的内部逻辑，但我们在这个架构中让它成为公有的-public，是因为我们可以在 EditorAssembler 类中集中控制它的调用，而且每一个 EditorComposite 都会有装载初始化数据和显示已有数据的行为，那么为什么不抽象出来呢，以便让 EditorComposite 的开发提供者更清楚自己的职责，虽然这么做有点破坏 EditorComposite 的封装性和其中方法的私密性，但从架构的角度来讲这种破坏是合适的，值得的。

　　再看看前面的 EditorAssembler 类，它其实有两个职责，一个是创建 EditorComposite，还有一个就是从几个 EditorComposite 选择出一个的判断逻辑。如果我们把这两个不相干的职责解耦，应用 Factory 设计模式，就可以将创建 EditorComposite 的工作委任给一个 EditorCompositeFactory 的新类。

　　经过以上几项重构后得到以下概念类模型：

　　图4. 概念类模型