public class MainProgram 
{ 
public static void Main() 
{ 
Console.WriteLine("Please Input a 0-100 Number:"); 
int input = Console.Read(); 
if (input < 0 || input > 100) 
{ 
Console.WriteLine("Error"); 
} 

Subject s = new Subject(); 
//给事件绑定方法，静态的 
s.NumberReached += new NumberEventHandler(msgbox_NumberReached); 
MainProgram mp = new MainProgram(); 
//给事件绑定方法，实例方法 
s.NumberReached += new NumberEventHandler(mp.console_NumberReached); 
s.DoWithLoop(input); 
Console.Read(); 
} 
void console_NumberReached(object sender, NumberEventArgs e) 
{ 
Console.WriteLine(e.Number.ToString()); 
} 
static void msgbox_NumberReached(object sender, NumberEventArgs e) 
{ 
MessageBox.Show(e.Number.ToString()); 
} 
} 
} 

   虽然这个例子代码多多了，但是是值得的，事件触发的地方和处理的地方完全分离了，循环的位置不再需要知道有多少个方法正等着处理它

总结

    经过几篇设计模式文章的介绍，也许有人会觉得设计模式一直在尝试解决几个问题：解藕，封装变化。设计模式一直在为可维护性，可扩展性，灵活性努力着。所以学习设计模式并不是了解设计模式的原型，重要的是了解设计模式的场景和目的，这样你也可以在你自己的工作中总结出自己的设计模式。
有人说中国的数学教育是个错误，学习数学并不是学习那些定理公式，学习那些东西永远是跟在别人的后面，学习数学应该注重数学史的学习，循着数学发展的历史，了解前人是怎样分析问题，解决问题，学习前人的“渔”，并不仅仅是为了得到“鱼”。

    本来上面的文章已经写定了，但今天看一MVP的文章又有点新的感触，觉得上面的总结又有点偏颇，学习模式重要的是她的精髓，但是“作为初学者即使知道所有设计原则但是却不知道如何在项目应用”。是的，也许学习设计模式也要从“量变”引起“质变”。大量的应用，先不管是否是过度设计，到一定的时候也许就会得到思想上的升华。