delegate与模式

    GoF的《Java与设计模式》一书就不再说其中的重要性了，这里主要想谈一下.Net中的Delegate对设计模式的影响。
    与Java相比.Net的一个比较好的改进是为事件提供了一个比较好的模型，其中的第一功臣是Delegate，那么Delegate的作用是什么？
    简单的来说Delegate是一个函数接口+一个函数列表。
    函数接口可以说是函数编程（之后简称FP）里面的思想（最近学习了一下FP）。FP的最核心思想是：函数是一等公民，即可以求值，也可以当作变量。回过头来看一下.Net这个主要是面向OOP的框架，但是它确实也吸收了FP的核心思想，在.Net里面，不能把函数当参数，但是，可以把函数转换成一个Delegate，再将这个Delegate做参数。于是，FP里面的高阶函数（说白了就是输入或输出一个函数的函数）、Lambda表达式都成为可能。那么在一个函数为王的世界里面，怎么定义一个接口？函数的接口就是它的返回值和它的参数。想一下，Delegate和它多么相似，定义一个Delegate也只需要返回值和参数。
    由于Delegate这个函数接口的存在，于是在.Net里面观察者模式不是必需的，不再需要定义一个接口了，因为有函数接口了。
    同时，因为Delegate这个函数接口的存在，完全可以简化很多逻辑，最主要的例子就是void List<T>.Sort(Comparison<T> comparison)，这个方法封装了一个快速排序法，但是，这个方法允许注入一个比较大小的函数。因此，当需要一个自定义的比较大小时，需要做的仅仅是写一个如何比较大小的方法，而不需要从头到位的写一个排序法，因为完全可以共享List<T>中封装的快速排序法。
    回到主题，有了Delegate后，可以把现在流行的Java模式衍化出新的.Net模式，简化一部分代码，却有继续保持着模式该有的开闭原则。
    观察者模式就省略了，相信没多少人在.Net中用观察者模式吧。
    以下优缺点中都省略了一条共同的缺点：虚方法的执行效率比Delegate高
--------------------以下纯属原创，名称全是随便取的----------------------
    1、简单工厂模式——>Delegate简单工厂模式：
    当简单工厂的产品IProduct中仅仅只有一个方法时，就可以用返回一个Delegate的工厂来代替。
    优点：1、不需要写一个IProduct接口，用一个Delegate代替
    缺点：1、IProduct可以添加其他的函数，而Delegate则不行
    2、只有一个类的访问者模式——>简化版的访问者模式：
    当访问者模式只需要处理一个类的时候，可以简化访问者模式如下：

    interface IVisitable<T>
    {
        void Visit(Action<T> action);
    }

    优点：不需要IVisitor接口
    缺点：只能用于单个类
    略。。。
-----------------------------------总结---------------------------------
    总之，当一个接口仅仅是为了一个方法而存在时，就可以用一个Delegate来代替，因为Delegate本身就可以被理解为一个函数接口。