08年国家经历全国雪灾冰雹，又有西藏达赖闹事儿，四川地震的创伤，南方洪涝，北方也避免不了，再加上南亚经济危机，国际物价上涨，对我国老百姓无疑是一次劫难。在现实社会里有些企业表面上响应国家号召，给员工加薪减量，背地里却给员工带来的无非是杯水车薪，还要加班加点的干。通货膨胀带来的后果是货币贬值，民生问题得不到保障，随着中国富人增多，相对贫穷的人也会增多，这是CPI过高带来的结果，贫富差距拉大，居民生活失衡。想买房的，只能眼看着富人买房，自己琢磨着不知还要当多少年房奴；买过房的，收入不稳定，还要担心月揭什么时候才算完。就算买过房的，再闹个地震，闹个水灾什么的，城区规划搬迁什么的，那就不好说了。我相信上帝也肯定在天上发愁：怎么这么多人需要救济啊？！

    这儿闹，那儿也闹，没完没了，对于老百姓来说08年是个苦命年，不收庄稼还吃啥，外粮贵如油。摘自一位时寒冰网友的博客中写到：
我要对《XX报》说的是，关注民生，维护社会公平和正义，绝不是什么“都老掉牙了”的问题；中国高房价中包含的巨大泡沫也隐藏着重重危机，也绝不是“都老掉牙了”的问题；解决住房问题，避免住房这一民生问题的恶化，维护居住这项基本权利，也绝不是“都老掉牙了”的问题。正视这些现实问题并推动问题的解决，是有责任感的媒体的责任。
    需要强调的是，即使从绝对值上来看，我国房价也已经非常高了。美国商务部最近公布的数据显示，今年3月份，该国新屋销售中间价创下近40年来最大跌幅，新房（独栋，相当于中国的别墅）销售中间价为每套22.76万美元，这种精装修的面积大都在200平方米以上的房屋，折合成人民币单价也不过每平方米8000元左右。而2007年我国新住宅（相当于美国的公寓）销售的平均价格为3655元/平方米。如果考虑到我国的房价是毛胚房，质量和品质低于美国，且不包含土地所有权（我们只有70年使用权），再考虑到美国人的人均收入是中国的30倍，我们高房价问题还是“都老掉牙了”的问题吗？
    像狗一样对既得利益集团奴颜婢膝、溜须拍马、摇尾乞怜，维护其利益，媒体或许能够得到更多的广告与赞助，媒体从业人员或许能够得到一系列好处，但是，充当强势利益集团的二奶或者奴才，是要以出卖新闻人的职业道德与良知为代价的！
    在中国媒体中，《XX报》曾经被人寄予厚望，它高高举起的巨大无比的牌坊像萤火虫的屁股一样闪烁于神州大地，被同业人员一度视为楷模，我希望它不是走向堕落，而是以实际行动证明它竖立起来的牌坊是货真价实的。
    这样的评论让我们陷入了深深的沉思，希望国家主导解决该问题。

    再关注一下学生上学和就业问题，要说中国的学生，我相信比任何国家的学生都多，大学扩招这几年，确实造就了很大一批高素质人才，现在热门的专业毕业以后也不见得能找到好工作，没有实际工作经验，用人单位也不可能用你，每年大学毕业生都是百万级别，而且现在大多数高中生高考完，就要报选专业，冷门的专业当然都不愿意选了，因为都怕找不到好工作。而且现在有一定工作经验跳槽的人也比较多，大多都是因为种种原因跳槽。像我这种不得已跳槽的人应该也有，当然已经没那么多了。上学、就业、生活是很大的难题。做为80后的真为以后担心，更为90后的弟弟妹妹们担心。

    根据这两年的经济情况和热门专业，来看一下2007年的统计数据：
    根据对2007年各本科专业初次就业率的统计，就业率位于前60位的专业分别是：金融工程、园艺教育、机械制造工艺教育、机电技术教育、电气技术教育、汽车维修工程教育、烹饪与营养教育、市场营销教育、德语、法语、西班牙语、生物科学与生物技术、地质学、地球化学、地球物理学、大气科学、微电子学、采矿工程、石油工程、矿物加工工程、勘查技术与工程、资源勘查工程、地质工程、矿物资源工程、冶金工程、金属材料工程、高分子材料与工程、材料科学与工程、机械设计制造及其自动化、材料成型及控制工程、过程装备与控制工程、机械工程及自动化、车辆工程、测控技术与仪器、热能与动力工程、核工程与核技术、电气工程及其自动化、电气工程与自动化、建筑学、道路桥梁与渡河工程、港口航道与海岸工程、安全工程、油气储运工程、飞行技术、航海技术、轮机工程、船舶与海洋工程、轻化工程、纺织工程、飞行器设计与工程、飞行器动力工程、飞行器制造工程、探测制导与控制技术、信息对抗技术、工程力学、森林工程、木材科学与工程、茶学、基础医学、国际商务。

    想到前几年,有人说国家制度不好,没钱赚,学生不容易。现在看看，现在的制度比以前更难赚钱，虽然说有更多的机会。现在学生也不好做，学费的压力，物价上涨，升学压力，就业压力，接蹴而来。有人说有钱人越来越有钱，不是家有基础就是坑蒙拐骗。这句话也不无道理，有部分人还是靠这个发家的。当然我更崇拜白手起家的那些企业家，人不坏，够仁义，才是英雄。表面一套，背地一套，那是小人。中国历来讲究道德礼仪，现在坏的风气，影响了现代社会，侵蚀了校园。林子大了，什么事儿都有。希望社会和政府能够协调好民生的问题，多关注老百姓，改革有序的社会，少一些社会弊端的小道消息。

    MVC作为一种开发模型，通常用于分布式应用系统的设计和分析中，以及用于确定系统各部分间的组织关系。对于界面设计可变性的需求，MVC(Model-View-Controller)把交互系统的组成分解成模型、视图、控制器三种部件。
　　视图部件把表示模型数据及逻辑关系和状态的信息以特定形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。
　　控制器部件是处理用户与软件的交互操作的，其职责是控制提供模型中任何变化的传播，确保用户界面于模型间的对应联系；它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制，是使模型和视图协调工作的部件。
　　模型部件保存由视图显示，由控制器控制的数据；它封装了问题的核心数据、逻辑和功能的计算关系，它独立于具体的界面表达和I/O操作。
　　模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。
模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示：

    ASP.NET MVC提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决稀释耦合系统的方法。

视图(Views)
    视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护，提高了开发效率。
　　在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图组成；子视图可以是最简单HTML控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。
　　视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给业务实体即模型。
　　这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：配置文件有模板配置、页面配置、路径配置、验证配置等。

控制器(Controllers)
    为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求，决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。
　　用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。
　　为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET提供低级别的请求/响应API，使开发人员能够使用.NET框架类为传入的HTTP请求提供服务。为此，必须创作支持System.Web.IHTTPHandler接口和实现 ProcessRequest()方法的类即：请求捕获者类，并在web.config的＜httphandlers＞节中添加类。ASP.NET 收到的每个传入HTTP请求最终由实现IHTTPHandler的类的特定实例来处理。IHttpHandlerFactory提供了处理 IHttpHandler实例URL请求的实际解析的结构。HTTP处理程序和工厂在ASP.NET配置中声明为web.config文件的一部分。ASP.NET 定义了一个＜httphandlers＞配置节，在其中可以添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory和HttpHandler的设置。HTTP处理程序和工厂是ASP.NET页框架的主体。工厂将每个请求分配给一个处理程序，后者处理该请求。 例如，在全局machine.config文件中，ASP.NET将所有对aspx文件的请求映射到HttpCapture类：
＜httphandlers＞
...
＜add verb="*" path="*.ASPx" type="Sys.UI.HttpCapture, Sys.UI"/＞
...
＜/httphandlers＞

模型(Models)
    MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的业务逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。
　　通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性，具有低耦合的效果。它可以轻松实现以下功能：
　　①实现一个模型的多个视图；
　　②采用多个控制器；
　　③当模型改变时，所有视图将自动刷新；
　　④所有的控制器将相互独立工作。
　　该模式下视图、控制器、模型三者之间的示意图如图2所示:

同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET面向对象编程的未来方向。

IoC(Inversion of Control)控制反转容器
    IoC将处理事情的责任从应用程序代码转移到框架，在软件开发技术中是一种通过容器管理对象约束关系。控制反转意味着在系统开发过程中，设计的类将交由容器去控制，而不是在类的内部去控制，类与类之间的关系将交由容器处理,一个类在需要调用另一个类时,只要调用另一个类在容器中注册的名字就可以得到这个类的实例,与传统的编程方式有了很大的不同,”不用你找,我来提供给你”,这就是控制反转的含义。
IOC的机制是:处理类之间和接口之间或类与接口之间关联关系,调用着与被调用者的主次关系,实现开关的原则。类之间可以很好(甚至)可以完全避免耦合,一个类只负责自己逻辑功能代码,如果想调用其它类告诉IOC容器去做(一种比较好的方式是根据配置文件来设定复杂关系),而不需要在代码上过多的编写。

MVC设计模式的优点及不足之处
　　MVC的优点体现在以下几个方面：
　　（1） 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。
　　（2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
　　（3） 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
　　（4） 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。

　　MVC的不足体现在以下几个方面：
　　（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
　　（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
　　（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
　　（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

    MVC对我来说，我也学习了有段时间了，结合了ASP.NET MVC Preview 2和ASP.NET MVC Preview 3两个Demo来学习微软提供的新框架，分析他们的不同之处，可以说这里面应用了很多新技术，例如Ajax、Linq、设计模式、页面跳转，还可以加入Web Service,这些技术和思想，我认为当你对MVC思想成熟时，也可以用在WinForm的开发中，虽然说其中有缺点，也有优点。与软件所处理问题的内在模型相比较，用户界面是需要经常发生变化的，采用MVC设计模式可以在满足对界面要求的同时，使软件的计算模型独立于界面的构成。也可以基于此模型建立大型分布式应用程序框架。最近经过本人的努力，已将MVC应用于一对外项目上，并且囊括了Ajax、设计模式、泛型程式一些技术，在此基础上，经过努力完成了对家庭理财软件的移植技术，我想这是我最近一段时间来最大的欣慰和回报。

参考：网络资源、ASP.NET MVC Preview 3框架、相关MVC Demo

    我曾经用过vss的多个版本，目前来讲，我用的是vss2005，当然新的版本肯定有不少的新的变化，新版本提供了两种安装方法：一种是按照常规的方法来安装部署的；一种是基于IIS站点来部署的。至于集体的安装方法可以参考相关资料来解决，服务器和客户端同样需要安装vss2005,基于共享的IIS站点来连接的，目前我主要应用于局域网内。vss提供了很多功能，它能够为我们做什么呢？现在我们来了解一下功能：
    你可以通过使用VSS，在特定卷上建立数据拷贝时间点；并在将来的某一时刻把数据恢复到任何一个你曾创建的时间点的状态。这两个Microsoft大肆吹捧的主要功能可以帮助客户的计算机恢复意外删除的文件，这样的工作即使一般员工也能轻松完成，并且不需要创建高效备份策略的能力。
　　对于IT技术支持人员来说，最常见的请求一般是恢复人为原因造成的数据丢失。用户不经意地存储了有错误信息的文件，不小心删除文件，或是其他的数据意外，都是经常发生的。
　　当用户需要重新找回数据的时候，经常需要请技术支持人员拔出备份磁带，进行人工恢复，这个工作相当浪费时间。
　　VSS让管理员能够在服务器上发布共享文件夹，在一定的时间间隔内做时间点的备份（在指定时间内最多可以存在65份拷贝）。这让最终用户能够安全地处理文件并随时恢复到早前的版本，而不需要IT部门的干涉。

VSS的不足：
    服务唯一的缺点是你需要为每一个卷影留出更多的磁盘空间，因为你必须在某处存储这些拷贝。不过，因为VSS使用指针数据，这些拷贝占用的空间要比你想像的小得多，你可以有效地存储这些拷贝。
　　你还可以将复制与备份工具和VSS配合使用，来将拷贝移动到另一个VSS——其他站点的可用服务器。因此，如果原始服务器在灾难中崩溃了，你的最终用户还是可以访问他们的数据。由于VSS在一定时间间隔内做一次快照，并且在母文件使用时并不锁定它们，因此开放文件锁定并不会影响到复制与备份工具。
　　除了复制开放文件以外，你还可以在最终用户处理文件的时候备份VSS快照。这一功能通过消除备份窗口、开放文件锁定和其他的障碍，显著地提高了备份能力。
　　你或许还将遭遇CPU利用问题（在运行备份代理的时候）和LAN利用问题（在跨越网络进行数据备份的时候），不过这并不妨碍最终用户使用文件。
　　备份VSS快照产生干净的数据镜像以及恢复时间点拷贝的能力。你既可以恢复整个快照，也可以取你所需，或者你还可以使用VSS备份工具来恢复单独的文件和文件夹。
　　因为你基于时间点来备份文件拷贝，所以可以很轻松的使用复制工具即时地将VSS快照移动到另一台灾难恢复站点中的服务器上，并在那里进行备份，创建脱站的缺省备份。需要将备份保存在脱站位置的公司会发现实施灾难恢复（DR）系统变得相当简单，而且备份系统能平滑地协同工作。

注意事项：
1.在配置服务器时，一定要注意，先安装.Net Framework 2.0，vss是基于Internet访问是通过Web Service实现的，所以安装前要先配置安装好IIS。
2.还有网络的问题，如果网络经常丢包，这样的网络是不稳定的，有可能出现网络中断的可能。
3.最好在登录vss服务器时，不要用Administrator帐户，应该开一个别的Guest帐户，不过采用vss2005是采用Internet的，就无须采用硬盘影射的方法了。
4.有时候会遇到潜入一个大文件时，vss会停止响应，现在都有补丁包了，最好升级一下。
5.如果你在客户端连接vss服务端出现问题是，很可能是网络不稳定，还有就是在创建web service是出现问题，这样就需要我们细致检查一下。

    希望广大网友踊跃交流，当然vss2005还有很多技巧，需要大家慢慢去发现，有什么问题可以与我进行交流，此文疏漏之处，还请大家多多包涵！

*这种设计布局比较紧凑，空间利用的非常好，适合幸福家庭装修。

*这种布局也很不错哦！很宽敞，相信普通的家庭也非常满意，自我感觉比较大众化。

*我要是能住上这样的房子，这样的客厅，还有窗外的美景，是多么美好的事情啊！品一杯美酒，散发出异样的感觉。

*简单的家什，不一样的感觉，相信你的眼光和我的一样。

*生活充满和谐的气氛，给你的生活增添了不少光彩，享受这一刻的快感。

*休闲娱乐的大家庭，现代感比较强，透着人文气息，体现“我爱我家”的理念。

*这样的布局岂能错过，好好品位窗外海边的美景，娱乐休闲、度假两不误。

*大气派，家庭和睦，其乐融融，幸福的大家庭，这样的装饰是少不了的。

你的观点是不是和我的一样呢？呵呵...,如果你爱你家，就应该好好装饰一番。我喜欢看这些美图，这些能够提高你的素养，想、看并快乐着！

    所谓“耦合度”，就是指程序之间的一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。
耦合强度高低，依赖于以下几个因素：
（1）一个模块对另一个模块的调用；
（2）一个模块向另一个模块传递的数据量；
（3）一个模块施加到另一个模块的控制的多少；
（4）模块之间接口的复杂程度。
一般在程序开发中应尽量避免完全依赖某一模式方法，根据不同情况，降低模块之间的耦合度。
高耦合发生的情况是：
(1) 一个模块直接访问另一个模块的内部数据;
(2) 一个模块不通过正常入口转到另一模块内部;
(3) 两个模块有一部分程序代码重叠(只可能出现在汇编语言中);
(4) 一个模块有多个入口。
软件功能模块的设计和划分按照OO（面向对象）的思想，遵循“强内聚，弱耦合”的原则，也就是尽量将相互依赖的类放在一个命名空间（包）中，内部结构和联系要尽量紧密——强内聚；对外模块尽量与其他方法或功能减少耦合---弱耦合，以便功能上或代码上可以达到重用，再组合新功能的时候，可以像搭积木一样，分别拿出去再重用，而不会太关联其他。[紧耦合、 松耦合就是强耦合和弱耦合]，其实在软件工程里已经提高这些概念。

    委托也很明显的体现了高聚合，低耦合的一个特征。委托的价值并不在于它能帮你解决什么难题，而在于它能帮助你优化你的程序。很多情况下不用委托我们也能完成工作，也许偶尔会觉得使用委托更加麻烦，但是正如前面所说委托能使代码更加的低耦合，更加具有可读性，更加容易根据需求的改变而改变，也更加的简少了代码量。下面我来举一个委托的例子：
有一个运动员，他叫green，他每周要训练三天，周一，周二和周三。而他每天训练完成后都要做不同的事情，但是这些事情是有规律的，他周一要将训练的分数交给manager，周二不用交了，但是他要自己记录下这个分数，周三他不用交也不用记录，但是他要把他的分数给他的队友看。
定义一个委托，使用delegate关键字，后面跟上他的参数，这个委托是要委托他去处理dosomething中的方法的，所以委托和这些方法的签名要一致。
        public delegate void MyDelegate(object sender, CustomeEvetnArgs e);
于是有了这个助手，green轻松多了，他终于不用管今天是星期几了，我们重新改一下player类，这个类中去掉了thedate属性，也没有了if，只有一个委托oncomplete事件在运动员OnComplete时触发
public class player
        {
            private string _code;
            public string Code
            {
                get { return _code; }
                set { _code = value; }
            }
            public event MyDelegate oncomplete;
            public void OnComplete()
            {
                CustomeEvetnArgs e = new CustomeEvetnArgs();
                e.Code = this.Code;
                if (oncomplete != null)
                { oncomplete(this, e); }
            }
        }
而这个助手要看今天是星期几，然后执行相应的方法，date是今天的日期。
            DoSomeThing things = new DoSomeThing();
            if (date == "Mon")
            { green.oncomplete += new MyDelegate(things.GiveCodeToManager); }
            if (date == "Tues")
            { green.oncomplete += new MyDelegate(things.RecodeCode); }
            if (date == "Wed")
            { green.oncomplete += new MyDelegate(things.GiveCodeToOthers); }
            green.OnComplete();
            Response.Write(result);

这样万一游戏流程有了改变，那也跟green无关了，他只要专心训练，其他的由这个助手进行改动。
委托可以通过+=，-=来增加和消除他在星期几所委托的方法。
高聚合 低耦合，是委托的一个很重要的用途。

   耦合度的解释，我都在上面提到了，很大程度上都是为了降低耦合度。在程序开发中，每一样事物都有两面性，我以前提到过这样的观点。有时候，或者说，在某种情况下，耦合度高的也为何不可。这篇文章是我仓促写出来的，也许质量不高，至少能够起到画龙点睛的作用。欢迎大家批评指正！

**********************************************************************************************************

*该图是四川北川堰塞湖水位上涨，已淹没一个乡，但淹没不了我们中国人的心。深切哀悼这次灾难中牺牲的人们和勇士们！

*该图是四川北川堰塞湖旁的整座大山溃塌，可以很清楚的看到这次地震的威力，大山崩塌堵塞河道形成危险的堰塞湖，很可能导致大坝溃堤。

*该图是这次地震造成的大山塌方，村庄被毁，连空降人员的立足之地都没有。

*该图是四川北川堰塞湖上涨，淹没了很多村庄，人们的家园被毁，失去了亲爱的家人，失去了美好的生活！

*该图是二零零八年五月十九日四川汶川大地震造成泥石流掩埋的一个村庄，泥石流侵袭了我们同胞的家园，掩埋了整个村庄，掩埋了田地，掩埋了牲畜，掩埋了我们的同胞，掩埋了往日的宁静的生活。现在被弥散的凄凉所笼罩着。

*该图是2008年5月19日，一艘运送物资的冲锋舟从映秀镇返回都江堰，在经过狗脚湾峡谷时，突然遭遇山体塌方，山上滚落的巨石在峡谷中溅起浓浓烟尘。冲锋舟正逃出生天。勇敢的人们正在与大自然抗挣。

*该图是四川汶川地震后，尸体散落街头的景象，已经是人间地狱，让我们为这些孩子们祈祷！  

*该图是在这次地震中遇难的孩子们和同胞们。他们已经离开了人间，我们为他们送行！为可怜的孩子们送行！

*2008年5月19日~5月21日是中国哀悼日，全国人民全体哀悼！降半旗致哀！

*******************************************************************************************

职责链模式(Chain of Responsibility):
我们来看看职责链模式是什么样的模式，它的定义是使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
通常在以下三种情况下使用：
1.有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定;
2.你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求;
3.可处理一个请求的对象集合应被动态指定。
我们来看一个结构图：

接下来我们来看看具体的实例：
namespace ChainOfResponsibility.DesignPattern
{
    using System;
    abstract class Handler
        {
           protected Handler successorHandler;
           abstract public void HandleRequest(Request request);  
           public void SetSuccessor(Handler sucessor)
               {
                   successorHandler = sucessor;
               }
        }

     class ConcreteHandler1 : Handler
        {
           override public void HandleRequest(Request request)
               {
                   if (request.RequestType == 1) 
                      {
                          Console.WriteLine("request handled in ConcreteHandler1");
                      }
                  else
                     {
                         if (successorHandler != null)
                            successorHandler.HandleRequest(request);
                     }
               }
         }

     class ConcreteHandler2 : Handler
        {
            override public void HandleRequest(Request request)
                {
                    if (request.RequestType == 2) 
                       {
                          Console.WriteLine("request handled in ConcreteHandler2");
                       }
                    else
                      {
                           if (successorHandler != null)
                              successorHandler.HandleRequest(request);
                      }
                 }
         }

     class ConcreteHandler3 : Handler
        {
            override public void HandleRequest(Request request)
                {
                    if (request.RequestType == 3) 
                       {
                          Console.WriteLine("request handled in ConcreteHandler3");
                       }
                   else
                      {
                          if (successorHandler != null)
                             successorHandler.HandleRequest(request);
                      }  
                }
        }

     class Request
        {
            private int iRequestType;
            private string strRequestParameters;
            public Request(int requestType, string requestParameters)
                {
                    iRequestType = requestType; 
                    strRequestParameters = requestParameters;
                }
            public int RequestType
                {
                  get
                      {
                          return iRequestType;
                      }
                  set
                     {
                         iRequestType = value;
                     }
                 }
         }

    public class Client
        {
            public static int Main(string[] args)
                {
                   Handler firstHandler = new ConcreteHandler1();
                   Handler secondHandler = new ConcreteHandler2();
                   Handler thirdHandler = new ConcreteHandler3();
                   firstHandler.SetSuccessor(secondHandler);
                   secondHandler.SetSuccessor(thirdHandler);
                   Request newRequest = new Request(2,"This are the request parameters");
                   firstHandler.HandleRequest(newRequest);
                   return 0;
                }
        }
}

访问者模式(Visitor Pattern):
在程序中用访问者模式有什么用处呢？访问者模式主要表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
通常在以下三种情况下使用：
1.一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作;
2.需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作;
3.定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。
接下来看一下具体实例代码：
namespace Visitor_DesignPattern
{
    using System;
    abstract class Visitor
        {
           abstract public void VisitElementA(ConcreteElementA a);
           abstract public void VisitElementB(ConcreteElementB b);
        }

    class ConcreteVisitor1 : Visitor
       {
          override public void VisitElementA(ConcreteElementA a)
              {
   
              }
         override public void VisitElementB(ConcreteElementB b)
             {
   
             }
       }
  abstract class Element
      {
         abstract public void Accept(Visitor v);
      }

  class ConcreteElementA : Element
     {
        public Visitor myVisitor;
        override public void Accept(Visitor v)
            {
               myVisitor = v;   
            }
        public void OperationA()
            {
   
            }
        public void DoSomeWork()
            {
                myVisitor.VisitElementA(this);  
            }
     }

 class ConcreteElementB : Element
    {
       override public void Accept(Visitor v)
           {
   
           }
       public void OperationB()
           {
   
           }
    }

public class Client
    {
        public static int Main(string[] args)
            {   
                ConcreteElementA eA = new ConcreteElementA();
                ConcreteElementB eB = new ConcreteElementB();
                ConcreteVisitor1 v1 = new ConcreteVisitor1();
                eA.Accept(v1);
                eA.DoSomeWork();
                return 0;
            }
    }
}

    到目前为止，所有的设计模式已经讲完。有些问题可能理解的不到位，但这是我的理解，只希望能够通过这些实例融入自己的智慧，做好自己的事儿，完善自己的代码规范化。欢迎网友、博友批评指正！

解释器模式(Interpreter Pattern):
首先来介绍一下解释器的定义，给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
在使用情况方面，有三种情况下经常使用：
1.当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式;
2.该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间;
3.效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。
我们先来看一下图示：

下面具体看一下具体实例：
namespace Interpreter.DesignPattern
{
    using System;
    using System.Collections;
    class Context
       {
  
       }

   abstract class AbstractExpression
       {
           abstract public void Interpret(Context c);
       }

   class TerminalExpression : AbstractExpression
      {
          override public void Interpret(Context c) 
              {
   
              }
       }

   class NonterminalExpression : AbstractExpression
      {
           override public void Interpret(Context c) 
               {
   
               } 
      }

    public class Client
        {
             public static int Main(string[] args)
                 {
                     Context c = new Context();
                     ArrayList l = new ArrayList(); //really need a tree here!
                     l.Add(new TerminalExpression());
                     l.Add(new NonterminalExpression());
                     foreach (AbstractExpression exp in l)
                        {
                            exp.Interpret(c);
                        }
                    return 0;
               }
        }
}

状态模式(State Pattern):
我们先介绍一下状态模式的定义，允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
状态模式适用于什么环境下使用，其有两种情况：
1.一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为;
2.一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。
下面来看一下具体的代码实例：
namespace State.DesignPattern
{
    using System;
    abstract class State
        {
            protected string strStatename;  
            abstract public void Pour();
        }

     class OpenedState : State
        {  
            public OpenedState ()
                {
                    strStatename = "Opened";
                }
           override public void Pour()
               {
                  Console.WriteLine("...pouring...");
                  Console.WriteLine("...pouring...");
                  Console.WriteLine("...pouring...");
               }
        }
 
     class ClosedState : State
        {  
           public ClosedState()
               {
                  strStatename = "Closed";
               }
          override public void Pour()
              {
                  Console.WriteLine("ERROR - bottle is closed - cannot pour");
              }
        }

    class ContextColaBottle
       {
          public enum BottleStateSetting {
          Closed,
          Opened
           };
         OpenedState openedState = new OpenedState();
         ClosedState closedState = new ClosedState();
         public ContextColaBottle ()
             {
                CurrentState = closedState;
             }
         private State CurrentState;
         public void SetState(BottleStateSetting newState)
             {
                if (newState == BottleStateSetting.Closed)
                   {
                      CurrentState = closedState;
                   }
               else
                  {
                     CurrentState = openedState;
                  }
              }
         public void Pour()
             {
                CurrentState.Pour();
             } 
        }

    public class Client
        {
            public static int Main(string[] args)
                {
                   ContextColaBottle contextColaBottle = new ContextColaBottle();
                   Console.WriteLine("initial state is closed");
                   Console.WriteLine("Now trying to pour");
                   contextColaBottle.Pour();
                   Console.WriteLine("Open bottle");
                   contextColaBottle.SetState(ContextColaBottle.BottleStateSetting.Opened);
                   Console.WriteLine("Try to pour again");
                   contextColaBottle.Pour();
                   return 0;
                }
        }
}

策略模式(Strategy Pattern)：
我们先来了解一下策略模式的定义，定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
策略模式主要适应以下几种情况：
1. 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法;
2.需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式;
3.算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构;
4.一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
接下来我们来分析一下具体实例：
namespace Strategy.DesignPattern
{
    using System;
    abstract class Strategy
        {
           abstract public void DoAlgorithm();
        }
    class FirstStrategy : Strategy 
       {
           override public void DoAlgorithm()
               {
                  Console.WriteLine("In first strategy");   
               }
       }

   class SecondStrategy : Strategy
      {
         override public void DoAlgorithm()
             {
                Console.WriteLine("In second strategy");   
             }
      }

  class Context
     {
        Strategy s;
        public Context(Strategy strat)
            {
               s = strat;   
            }
       public void DoWork()
           {
           }
       public void DoStrategyWork()
           {
              s.DoAlgorithm();
           }
      }

    public class Client
        {
           public static int Main(string[] args)
               { 
                   FirstStrategy firstStrategy = new FirstStrategy();
                   Context c = new Context(firstStrategy);
                   c.DoWork();
                   c.DoStrategyWork();
                   return 0;
               }
        }
}

下面介绍观察者模式(Oberver Pattern)的定义和在什么情况下使用。
观察者模式定义了对象间的一种一对多依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
使用情况：
1.对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变。
2.对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。
下面来分析具体实例：
namespace Observer.DesignPattern
{
    using System;
    using System.Collections;
    class Subject                                                                             //Subject共有父类
       {
           private ArrayList list = new ArrayList();
           private string strImportantSubjectData = "Initial";       //初始化strImportantSubjectData
           public string ImportantSubjectData
               {
                   get
                       {
                           return strImportantSubjectData;
                       }
                   set 
                      {
                         strImportantSubjectData = value;
                      }
               }
          public void Attach(Observer o)
              {
                  list.Add(o);
                  o.ObservedSubject = this;
              }
          public void Detach(Observer o)
              {
   
              }
          public void Notify()
              {
                  foreach (Observer o in list)  
                     {
                         o.Update();
                     }   
              }
       }
    class ConcreteSubject : Subject                    //继承自Subject类的属性信息
       {
          public void GetState()
              {
   
              }
          public void SetState()
              {
   
              } 
       }
   abstract class Observer                               //抽象观察者类
       {
          protected Subject s;
          public Subject ObservedSubject
              {
                  get
                     {
                        return s;  
                     }
                 set
                    {
                       s = value;
                    }
              } 
         abstract public void Update();
       }
    class ConcreteObserver : Observer               //继承自观察者抽象类Observer
       {
           private string observerName;
           public ConcreteObserver(string name)
               {
                  observerName = name;
                } 
           override public void Update()                  //重写实例化Update方法
               {
                  Console.WriteLine("In Observer {0}: data from subject = {1}",
                  observerName, s.ImportantSubjectData);
               } 
        }

    public class Client
        {     
            public static int Main(string[] args)
                {          
                   ConcreteSubject s = new ConcreteSubject();
                   ConcreteObserver o1 = new ConcreteObserver("first observer");
                   ConcreteObserver o2 = new ConcreteObserver("second observer");
                   s.Attach(o1);
                   s.Attach(o2);
                   s. ImportantSubjectData = "This is important subject data";
                   s.Notify();   
                   return 0;
                }
        }
}

现在来看一下中介者模式(Mediator Pattern)的定义和在什么情况下使用。
定义：中介者模式是设计模式中一个比较常用的模式,他的原理比较简单,其实就是,把各个组件(对象)之间的复杂交互通讯通过其中的一个”中介者”来处理。
使用情况：中介者(midiator)模式通过提供一种松耦合的方式,解决对个对象之间复杂的交换问题。在这种模式中,只有一个类彻底清楚其他类的方法,当类发生变化时,他们会通知中介者,在由中介者将改变通知其他相关的类(对象/组件)。
看看具体的中介者实例：
namespace Mediator.DesignPattern
{
    using System;
    class Mediator
       {
           private DataProviderColleague dataProvider;
           private DataConsumerColleague dataConsumer;
           public void IntroduceColleagues(DataProviderColleague c1, DataConsumerColleague c2)
               {
                  dataProvider = c1;
                  dataConsumer = c2;   
               }
           public void DataChanged()
               {
                  int i = dataProvider.MyData;
                  dataConsumer.NewValue(i);
                }
        }
     class DataConsumerColleague                                  //消费者 
        {
            public void NewValue(int i)
                {
                   Console.WriteLine("New value {0}", i);
                }
        }
    class DataProviderColleague                                      //提供者
       {
           private Mediator mediator;
           private int iMyData=0;
           public int MyData
               {
                  get
                      {
                          return iMyData;
                      }
                  set
                      {
                          iMyData = value;
                      }
               }
           public DataProviderColleague(Mediator m)          //提供者方法
               {
                   mediator = m;
               }
           public void ChangeData()                                        //交换数据
               {
                  iMyData = 403;
                  if (mediator != null)
                  mediator.DataChanged(); 
               }  
       }

    public class Client
        {
            public static int Main(string[] args)
                {           
                    Mediator m = new Mediator();
                    DataProviderColleague c1 = new DataProviderColleague(m);
                    DataConsumerColleague c2 = new DataConsumerColleague();
                    m.IntroduceColleagues(c1,c2);
                    c1.ChangeData();
                    return 0;
                }
        }
}

接着讲备忘录模式(Memento Pattern)的定义和在什么情况下使用。
定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
使用情况：
1.必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。
2.如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
我们来看看具体的备忘录模式的实例：
namespace Memento.DesignPattern
{
    using System;
    class Originator
       {
           private double manufacturer=0;
           private double distributor = 0;
           private double retai