ESFramework开发手册系列文章已经详细介绍了如何使用ESPlus提供的ESPlus.Application.CustomizeInfo空间来发送和处理自定义信息，而且，在我们在前面介绍的demo中，也展示了如何定义信息类型、信息协议，以及如何实现ICustomizeHandler来处理接收到的信息。在一般业务简单的系统中，我们完全可以像demo一样，在一个CustomizeHandler类中处理所有的信息，将所有的业务逻辑集中在这一个地方。但是，当业务逐渐变得复杂时，你会发现，CustomizeHandler类会变得越来越大，而且有很多关联不大的业务逻辑也纠缠在了一起。根据“低耦合、高内聚”的设计原则，我们需要对这个变得复杂的CustomizeHandler进行拆分，将一个CustomizeHandler拆分为多个高内聚低耦合的类，对收到的信息进行分类，分而治之。
一.分而治之的设计阶段
就像刚才提到的，分而治之的所依据的最根本原则是面向对象的基本设计理念 -- 高内聚、低耦合。
在实际的项目中，高内聚、低耦合所针对的分析目标就是我们的业务逻辑， 所以，对CustomizeHandler进行拆分，实际上是对业务逻辑进行拆分。再进一步，那些将被处理的自定义信息，实际上是业务逻辑类型的一个侧面的展示，所以，归根到底，在编码时，最后就是对自定义信息的类型进行拆分。
假设某个项目的主要业务逻辑可以拆分为A、B、C三类，那么，自定义信息也可以分为A、B、C三类，我们的经验是这样的，将不同类别的信息类型的值（整数）划归到不同的整数段。比如，A类型的自定义信息的类型值为0-100，B类型为101-200，C类型为201-300，当我们要在某类业务逻辑中增加一个信息类型时，就要在对应的数值范围内增加一个数值。这样处理之后，当我们接收到一个自定义信息，根据其类型就可以判断出它是属于哪类业务的了。
在做系统设计时，我们的设计师通常会将所有的信息类型整理成一个“协议类型”文档并将其定义放到一个dll中，服务端和客户端开发人员都使用这个dll的定义，并遵循文档中的信息类型的规范描述。比如，针对上面的示例可以设计类似如下的“协议类型”文档：
二.分而治之的实现阶段
在将自定义信息分类并完成了信息的格式约定后，就可以实现信息处理器了。针对A、B、C三类业务，理所当然地，我们会实现三个信息处理器分别与之对应，假设命名为ACustomizeHandler、BCustomizeHandler、CCustomizeHandler。现在的问题是，实现了这几个处理器之后，如何将它们挂接到ESFramework/ESPlus框架上了？幸运的是，ESFramework/ESPlus为分而治之这种策略提供了完美的支持，我们不需要再手动去映射信息类型与对应的处理器。
ESPlus.Application.CustomizeInfo命名空间在服务端（Server）和客户端（Passive）都提供了IIntegratedCustomizeHandler接口 -- 可被集成的处理器接口，其定义如下所示：
///<summary>
/// 能够被ComplexCustomizeHandler集成的ICustomizeHandler。
///</summary>
public interface IIntegratedCustomizeHandler :ICustomizeHandler
{
///<summary>
/// 当前的处理器能否处理目标类型的自定义信息。
///</summary>
///<param name="informationType">自定义信息的类型</param>
///<returns>能处理？</returns>
bool CanHandle(int informationType);
}
IIntegratedCustomizeHandler从ICustomizeHandler继承，说明它可以做与ICustomizeHandler完全一样的事情，只不过，它处理的是整个业务逻辑的一个子集。其增加的CanHandle方法用于说明当前处理器能处理哪些自定义信息。ACustomizeHandler、BCustomizeHandler、CCustomizeHandler 只要实现IIntegratedCustomizeHandler接口就可以了。处理器实现新加的CanHandle方法很简单，比如BCustomizeHandler实现CanHandle的代码如下所示：
public bool CanHandle(int informationType)
{
return informationType >= 101 && informationType <= 200;
}
在实现完了各个业务处理器之后，接下来就需要将它们合成起来，并挂接到ESFramework/ESPlus框架上。
三.分而治之的合成阶段
先分后合，分而治之的最后阶段是“合”，只有将ACustomizeHandler、BCustomizeHandler、CCustomizeHandler统合起来，才能形成一个完整的业务处理器以处理接收到的所有自定义信息。
ESPlus.Application.CustomizeInfo命名空间在服务端（Server）和客户端（Passive）都提供了ComplexCustomizeHandler类，它是一个综合处理器，相当于一个包装，可以把ACustomizeHandler、BCustomizeHandler、CCustomizeHandler综合在一起，并且ComplexCustomizeHandler又实现了IIntegratedCustomizeHandler接口，这表明了两点：
- ComplexCustomizeHandler实现了IIntegratedCustomizeHandler接口，而IIntegratedCustomizeHandler又是继承自ICustomizeHandler接口，所以可以将其直接挂接到ESFramework/ESPlus框架。
- ComplexCustomizeHandler实现了IIntegratedCustomizeHandler接口，表明其可以再度被其它的ComplexCustomizeHandler集成。就像在一个巨型的系统中，业务逻辑可以被逐级向下拆分，最后可以通过ComplexCustomizeHandler逐级向上合成。
ComplexCustomizeHandler的实现原理很简单，它只是将接收到的自定义信息分派给正确的处理器去处理，而自己并不参与任何实际的业务过程。其类图如下所示：
针对上面的示例，我们将ACustomizeHandler、BCustomizeHandler、CCustomizeHandler的实例放到ComplexCustomizeHandler的HandlerList中，并且将ComplexCustomizeHandler对象注入到RapidPassiveEngine和RapidServerEngine的Initialize方法中，即可挂接到ESFramework/ESPlus框架。
四.更多说明
虽然，ESFramework/ESPlus为分而治之这种策略提供了很好的支持，但这并不是实现分而治之策略的唯一的模式。您完全可以抛开IIntegratedCustomizeHandler和ComplexCustomizeHandler，按照自己的习惯和方式，来拆分业务逻辑并进行合成，最后也会殊途同归－－只要我们遵循了“低耦合、高内聚”这一最根本的设计原则。