通过CreateConstraint()方法，就可以像穿珠子一般，形成一条隐藏的职责链（在创建这样的职责链时，需要注意职责对象的先后次序），然后在客户端代码中，可以非常优雅的实现对绑定的约束性检查：

private static BindingConstraint m_bindingConstraint = BindingConstraintFactory.CreateConstraint(); 

public void AddServiceEndpoint(ServiceEndpoint endpoint) 
{ 
if (m_bindingConstraint.Constraint(endpoint)) 
{ 
m_endpointsList.Add(endpoint); 
} 
} 

   不管传入的endpoint是何种类型的绑定，只要在职责链中创建了相对应的绑定约束对象，都可以进行约束性检查，且逻辑清楚，职责明确。如果对绑定进行了扩展，我们只需要新增对应的绑定约束对象，然后修改BindingConstraintFactory工厂类的工厂方法即可。

    使用职责链模式必须恰到好处，否则会成为模式滥用的反面教材。根据我对职责链模式的理解，可以认定只要同时符合下列三个条件，就可以引入职责链模式：
   1、当一个方法的传入参数将成为分支语句的判断条件时；
   2、当每一个分支的职责相对独立，且逻辑较为复杂时；
   3、当分支条件存在扩展的可能时。

   至于职责链模式的非常好的实践，则包含以下内容：
   1、应尽量将职责链模式的抽象定义为抽象类，而不要定义为接口。这样有利于一些公共逻辑的重用。
   2、应在实现职责链模式的同时，提供创建职责链的工厂类。