myRoad-委托

时间：2010-10-23 来源：风枫峰

首先是我们来做一个最简单的编程计算一加一等于多少，并且输出结果：

    Console.WriteLine("1+1={0}",1+1);  输出为 1+1=2

    那么这个代码有什么不好的地方呢？ 它只能计算1+1 但是用户是多变的 有的时候他会想2+2等于多少 。。。。。。。。

    那么为了应付用户的这个需要 我们需要改写一下代码：

    int a, b;
    a = int.Parse(Console.ReadLine());
    b = int.Parse(Console.ReadLine()); 
    Console.WriteLine("{0}+{1}={2}",a,b,a+b);

    这次我们用a,b两个变量来接收用户的输入，然后输出 a+b 的结果。好处就是 我们在写程序的时候不需要知道具体用户要运算哪两个数，

但是我们必须知道“业务”也就是用户是要用我们的程序进行两个整数的加法运算，并且要在屏幕上看到他输入的两个整数进行加法运算后的

结果。在啰嗦一句，用户关心我们怎么进行加法运算吗？  如果我写成：

    int a, b,c;
    a = int.Parse(Console.ReadLine());
    b = int.Parse(Console.ReadLine()); 
    c = a + b;
    Console.WriteLine("{0}+{1}={2}",a,b,c);

    这样比上次写的多了一个c变量，用户就不用我的软件了吗？  当然不是，用户更不不关心是怎样实现的加法运算，他只关心：

     “我需要付出什么东西，我能得到什么样的利益” 也就是 “我要Technorati 标签: 委托输入什么样的参数，能得到什么样的返回值”

   接下来我们的需求又改变了。。。 现在需要加，减，乘，除四种运算界面如下：

  代码：

  int a = int.Parse(tbFirst.Text);
  int b = int.Parse(tbSecond.Text);
  char sign = char.Parse(tbSign.Text);
  int c=0;
  switch (sign)
  {
     case '+': c = a + b; break;
     case '-': c = a - b; break;
     case '*': c = a * b; break;
     case '/': c = a / b; break;
     default:
        break;
  }
  tbResult.Text = c.ToString();

  现在我们改变一下想法，界面是一个人，业务是一个人，那么界面就是用户，业务就是程序员了，上面一段代码就相当于用户把所有工作都

做了，那我们吃什么，喝什么。再说用户也不会啊! 也就是说界面只关心我能得到什么数据，我要输出什么数据，别的我不管，那么这里就得

改写成

        private void btnCount_Click(object sender, EventArgs e)
        {
            int a = int.Parse(tbFirst.Text);
            int b = int.Parse(tbSecond.Text);
            char sign = char.Parse(tbSign.Text);
            tbResult.Text = Count(a, sign, b);

        }
        public string Count(int a, char sign, int b)
        {
            int c = 0;
            switch (sign)
            {
                case '+': c = a + b; break;
                case '-': c = a - b; break;
                case '*': c = a * b; break;
                case '/': c = a / b; break;
                default:
                    break;
            }
            return c.toString();
        }

这样界面调用Count函数得到计算后的结果。那么这种方法有个什么缺点呢？那就是在有"界面"的时候，已经有了“业务”，而且“界面”对“业务”相当了解，都知道他有什么样的方法，名字叫什么。这样是不是“界面”管的太多了，"你干好自己干的，管我的方法叫什么干什么？"业务想。其实本来也是，"界面"只要知道我要付出什么，我能得到什么就够了啊！这时委托就派上用途了

        public delegate string Count(int a, char sign, int b);
        Count count;
        
        public Form1()
        {
            InitializeComponent();
            //这里程序程序正真执行的时候才知道有aaa这么一个函数符合
             //得到三个变量，输出一个String类型。
             count += aaa;  
        }

        private void btnCount_Click(object sender, EventArgs e)
        {
            int a = int.Parse(tbFirst.Text);
            int b = int.Parse(tbSecond.Text);
            char sign = char.Parse(tbSign.Text);

            //这里“界面”根本不管实现计算的方法叫什么，只知道要调用一个函数
             //并且需要付出  a,b,sign 三个变量 然后得到一个结果是String类型的

             tbResult.Text = count(a, sign, b);
        }

        public  string  aaa(int a, char sign, int b)
        {
            int c = 0;
            switch (sign)
            {
                case '+': c = a + b; break;
                case '-': c = a - b; break;
                case '*': c = a * b; break;
                case '/': c = a / b; break;
                default:
                    break;
            }
            return c.ToString();
        }

也就是委托可以这样理解，定义了一个方法得到什么，付出什么，但不关心方法的实现，然后等具体要用的时候可以绑定符合条件的方法，也就符合了面向对象的松耦合。