委托，语言级别的设计模式

我们有个发票类，需要提供一个打印的方法，客户告诉我们，这个订单要提供多种打印的样式，那么我们一般会这样设计

 1    public enum CommercialInvoiceMode//商业发票样式
 2    }

这样的设计看似没有什么问题，用一个枚举可以描述发票不同的打印模式，仅提供一个PrintInvoice方法就可以实现对多种发票打印样式的处理，是不是自我感觉很良好啊？
不过这样的设计有些致命的缺点：
具体的实现打印的代码结构大致如下

 1    }

如果你对以上的代码没有什么歧义，那就说明你对类的开闭原则不是很了解。
为什么这样的设计不好呢？
比如用户要求有了新的打印样式
我们要修改枚举

 1    public enum CommercialInvoiceMode//商业发票样式
 2    }

修改了枚举，就必须要修改PrintInvoice方法中的switch代码，因为多了发票样式，就必须重新的修改类。重新的修改枚举，典型的破坏类的封装。
如果，你还是不同意这样的设计破坏了封装，那我们再考虑一个场景：要是以上的打印样式分别是两个客户提出的，难道你要两个枚举？

 1    public enum CommercialInvoiceModeA//商业发票样式
 2    }

如果有这两个枚举，那PrintInvoice方法马上要完全改变，这个类就不能通用了。必须为不同的客户提供不同的Invoice类，假设Invoice的数据和行为都一样，那就是说必须为了InvoiceStyle而实现不同的类。
而这些InvoiceStyleA和InvoiceStyleB类仅仅是打印的样式不同，其他的数据和行为都一样，所以这样的设计不完全合理。
我们需要一个Invoice类，该类的PrintInvoice能在不改变Invoice类的实现情况下，可以灵活的处理打印。
我们先设计一个发票打印类：

 1    public class PrintInvoice
 2    }

这个打印类，为每种打印提供了具体的实现，将来有了新的打印样式，仅仅是增加新的方法（可以直接为类增加或继承后增加），没有破坏类的开闭原则。
那这个类可以帮我们做什么呢？
我们观察一下，这几个方法的外观其实是一致的：同样的返回值，同样的参数列表。
让你想到了什么？接口？恩，是的，想想如果用接口的知识，我们现在能做些什么呢？
我们一定会设计如下的类：

 1    public interface IPrintInvoice
 2    }

然后我们的Invoice类如下设计：

1    public class Invoice
2    }

这个Invoice类设计的就非常的漂亮，符合开闭原则了。不过，不足的就是要写很多IPrintInvoice的实现类，每个类就一个PrintInvoice方法，这样的话，类实在太多了。不方便管理。
所以我们还是在我们先前的PrintInvoice类打主意。
C#提供了一种特殊的引用类型：委托。这个类型可以把我们的方法（函数）包装为独立的对象。然后就可以把这个包装后的方法（委托）当参数用。这个参数具有被包装函数的所有特征：有返回值和参数。就是说该包装后的对象其实就是一个方法（函数）。
我们来看一下，委托的声明。

1public delegate void PrintStyle(Invoice data);

就一行，没有{}的，在类外面声明（也就是说委托的级别和类、接口的级别是一样的）。
这个委托描述了，他可以帮助返回为void，参数为Invoice类型的函数，具体函数的名字它不管，它只要返回值和参数列表符合他的包装要求就可以了。
我们修改Invoice的PrintInvoice方法

 1    }

看看，第9行是不是用起来很接近接口的用法啊？参数PrintStyle方法传入的就是外观和delegate void PrintStyle(Invoice data)一致的函数，用这个PrintStyle就是调用一个函数。
看看具体的调用

1            Invoice invoice = new Invoice();
2            invoice.PrintInvoice(new PrintStyle(PrintInvoice.QuadruplicateStyle));

上面的代码就是把PrintInvoice的QuadruplicateStyle方法传递给了Invoice类的PrintInvoice，那么前端代码的第9行其实就是调用PrintInvoice的QuadruplicateStyle方法。

1            Invoice invoice = new Invoice();
2            invoice.PrintInvoice(new PrintStyle(PrintInvoice.QuadruplicateStyle));
3            PrintStyle printStyle = new PrintStyle(PrintInvoice.TriplicateStyle);
4            invoice.PrintInvoice(printStyle);
5            printStyle = new PrintStyle(PrintInvoice.DuplicateStyle);
6            invoice.PrintInvoice(printStyle);

委托再次提醒我们在类设计时的一个真理：直接的是最不稳定的，间接的才是最稳定的