博客园_王书奎(网名:无忌)

极限编程一概述

2012-04-20T04:29:00Z

极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通，一定要用客户理解的语言，先测试再编码就是先给客户软件的外部轮廓，客户使用的功能展现，让客户感觉到未来软件的样子，先测试再编码与瀑布模型显然是背道而驰的。同时，极限编程注重用户反馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过程，有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”，如结队编程、40小时工作等。

在XP的项目开发中，首先引入了

四个变量：

成本、时间、质量和范围，

通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。

为了能成功地实施XP，XP制定了

四个准则(核心)：

沟通、简单、反馈和勇气

和

十二条原则：

计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40小时、现场客户、编码标准

以及对开发人员的

工作要求：

编码、测试、倾听和设计。

提出这些要求和原则后，XP有提出了一系列的

解决方案(也就是策略)，

其中包含：

管理策略、设施策略、计划策略、开发策略、设计策略和测试策略。

在真正去实现XP时，XP又提供了

将策略成功应用的实践:

其中主要包括：

测试驱动开发、结队编程、重构和极限编程工具

四个核心:

极限编程的核心有四个，交流、简单、反馈和勇气，这四个原则大家在平时做项目的过程中一定也注意到了。但是两位大师Kent Beck 和 Martin Fowler能够把这四点归结在一起，使他们能够一起组成极限编程这架四轮马车，却是个不小的创造的。

下面仅就自己的学习和简单的实践过程中碰到的问题来谈谈自己对这四个核心的一些理解。

一、交流

1)       研发人员和客户的交流

这一点和传统的软件工程中有些类似，在平时研发软件的过程中也很注重和客户的交流，特别是在需求分析、概要设计连同验收测试的时候，研发人员和客户有效的交流是必不可少的，那将直接影响到一个项目是否能够符合客户的需要。

然而，在极限编程中客户所处的研发阶段有些不同，传统的项目研发过程中，客户只在最初的时候和最后的时候需要和研发人员在一起，他们的责任也就是在于业务功能上的帮助，但是这样就不可避免的导致了这样的一个状况：在项目最初的时候客户提出了错误的或不准确的需求，然后项目组开始研发，客户很长一段时间不介入项目，而在项目验收的时候发现有些地方有错误或需要修改，此时项目组不得不付出很多的时间和精力来适应客户的需求。这是时间和资金上很大的浪费。在极限编程中，需要一个很精通业务的现场客户，他们不但随时提供业务上的信息，而且要编写业务验收测试的测试代码，这样就能够在很大的程度上确保项目的方向不会错误。

极限编程的过程是“瞄准－》射击－》调整－》调整”的过程，并不强求在项目开始的时候就准确把握项目的方向，由于有现场客户的存在，项目的方向是不断的调整中的，这样就能够极大程度上避免项目走弯路。

2)       研发人员之间的交流

当前在招聘研发人员连同其他一切的工作人员的时候，我们都会强调团队精神，但是在实际的工作过程中，我们除了在出现问题，而且自己解决出现很大困难的时候才会去请教别人（我以前是这样的，可能每个人都会不同），再就是大家能够一起聚在一起闲聊、吃饭、唱歌等等研发过程以外的活动。以上的这些的确能够使团队之中产生一定的凝聚力，能够让大家和睦相处，但是离真正意义上的团队更有一定的差距。

我们所受到的教育一直培养的是一种单独解决问题的能力，所以，再碰到问题的时候我们想到的大多是自己来就解决，而不是和其他人一起来完成。

极限编程的实践中有一个很重要的原则就是结对编程，这个原则看起来似乎有些奇怪。因为我们第一个想到的问题就是让两个人来同时做一件事情，那么不就是浪费了一个人的生产力了吗？但实际上并非如此，这里所谓的结对编程并非是个人在编程，另一个在看着，另外一个人也同样起着很重要的作用，他的大脑也在不停地运转，他需要帮助编码的人找到低级的失误，防止其编码出现方向性的错误，特别是在出现一个正在编码的人不擅长解决的问题的时候，他会直接拿过键盘，和其交换角色，直接来进行编码。

这样做的好处也许只有在实践了之后才能够体会到，他不但能够避免一些错误的发生，而且能够通过直接的讨论来解决一些容易产生歧义的问题。而且两个人的思路碰撞出来的火花，能够更加快速的解决问题。而且，在交流的过程中，大家的水平也会有很快的提高。结对编程的过程也是一起学习的过程。（只可惜我这里只有一个人，没有办法长期实践，但只要有机会我就会努力的）

3)       研发人员和管理人员的交流

在一个项目组里面，管理人员和研发人员之间的关系是影响项目的一个很重要的因素，假如处理不好的化，可能会直接导致一个项目的失败。而管理人员所具备的素质更是需要很高的。假如是个从技术人员转型的管理者，那么他的管理能力需要很大的提高，否则就会因为管理能力的缺乏而导致项目的混乱。而对于一个单纯的具备管理技能的人来说，怎样能够得到技术人员的佩服是十分重要的，否则根本就无法使研发人员听从管理，那么他的位置也就岌岌可危了。

而且，假如研发人员能够和管理人员进行好的交流，那么他们的工作环境就会得到很大的改善，并不一定要很豪华的房间和高级的家具，只需要一个能够很舒服工作的环境，就能够让一个团队的战斗力得到很大的提升。而且，对于一个项目的计划和预算，假如研发人员能够提出自己的想法，就会避免最后争取到了项目却最终得不到利润的情况的出现。

管理人员也应该主动的听取研发人员的意见，很多的研发人员都是一些比较内向的人，假如不向他们询问，他们只会将自己心中的不满埋在心中，最后的结果是突然的爆发，然后辞职离去，造成重大的损失。

二、简单

1)       设计的简单

在极限编程的过程中，提倡一种简单设计的实践。这样做的原因是由于过多的设计文档会使我们浪费太多的时间在上面，而且设计文档没有不修改的，可能在项目结束的时候，我们会发现当初的设计文档早已使面目全非了。

所以，我们在最初的设计工作中要做的是明确我们要实现的最重要的功能，然后设计出总体的框架和核心的技术，这些文档从头到尾不会超过十页纸，那样即使有了一些改变，我们也无需花费太多的时间来进行修改了。特别是在有了修改之后，我们无需费很大的力气去让代码和文档完全一致了。

但是，简单的设计并不意味着这些设计是可有可无的，相反，那简单的几页纸更加重要，因为一个项目的核心内容都在上面，所以在编写的过程中一定要慎重。

2)       编码的简单

编码的简单表现在迭代的过程中，在极限编程的过程，并非要一下子实现任何需要的功能，也无需一下子就完成以后不再改变，相反，变化在极限编程中是被提倡的。我们能够先简单的实现一点功能，然后添加周详的内容，再后对程式进行重构，最终的代码将是很简单的，因为依照重构的原则进行修改了之后，任何的类和函数、过程都是很简短而非冗长的，每一个模块完成的功能是很明确的。

但是，不要把简单和随意等同起来。尽管我们要实现简单的编码，依然要有编码的标准，使得任何的人都能够很容易的看懂我们编写的程式。其他象属性要使用名词来定义，过程要使用动词来开头的标准也是很有用的，我们应该遵循。

3)       注释的简单

在某些项目中，注释需要是很严格的，甚至于规定在一个程式中注释量必须要达到一个百分比。这个初一看起来很有道理，因为注释能够让我们更好的理解程式的功能，但是细想一下，却完全不是那么一回事。

曾有人说过“一般的程式员能够编写出电脑能看懂的程式，而一个真正的高手能够编写出普通人也能够看懂的程式”。的确是那样，和其让注释来解释程式，不如在给变量和过程、函数起名的时候用大家都能够理解的，那样即使没有太多的注释，另外的一个程式员想要读懂您写的程式也不是一件很困难的事情了。

所以，在编写代码的过程中应该尽可能的使用代码本身来说明问题，而非借助注释的帮助，我们要编写的是代码，假如里面带有太多的无关轻重的代码，一方面会浪费我们的时间，还可能引起歧义；另一方面向微软的Windows源代码里面充满的发牢骚的注释就更不应该了。那些注释只是会给阅读代码的人带来分散注意力的效果了。

4)       测试的简单

通常我们的项目假如是按照瀑布式研发的化，测试会全部放在编码完成之后，其中包括单体测试，集成测试，功能测试连同验收测试等等，而且大多数的测试是通过手工来完成的。所以依据经验来说，假如编码使用了20％的时间，测试至少要用掉40％以上的时间。而且在测试的过程中，更有好多问题需要修改，这也是导致测试耗费了大量时间的原因。

而在极限编程中，测试是通过编写测试代码来自动化完成的。特别是在一些面向对象的编程环境中，我们能够使用xUnit工具来快速、有效的进行单体测试。而且编写这些单体测试代码甚至能够是在正式编码之前。每一次修改了程式之后，都要运行测试代码来看程式是否有问题。而且对于程式的集成，极限编程提倡的是持续集成，也就是不断的将编写好的通过了单体测试的代码模块集成到编写完毕的系统中，在那里能够直接进行Test Suit的集成测试，从而确保代码不会影响到整个系统。

我们能够看到，极限编程中的编码和测试都是一小步一小步的进行的，这样就方便我们及时的发现并修改出现的错误。而自动化测试工具确保了我们的工作的效率，使我们避免了过多重复的工作。

　　十二条原则：

1、角色定位：极限编程把客户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。客户是软件的最终使用者，使用是否合意一定以客户的意见为准。不仅让客户参与设计讨论，而且让客户负责编写拥护故事(User Story)，也就是功能需求，包括软件要实现的功能以及完成功能的业务操作过程。用户在软件开发过程中的责任被提到与开发者同样的重要程度。

2、敏捷开发：敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期，缩短到周、日，完成一个小的功能模块，可以快速测试、并及时展现给客户，以便及时反馈。小版本加快了客户沟通反馈的频率，功能简单，在设计、文挡环节大大简化。极限编程中文挡不再重要的原因就是因为每个版本功能简单，不需要复杂的设计过程。极限编程追求设计简单，实现客户要求即可，无需为扩展考虑太多，因为客户的新需求随时可以添加。

3、追求价值：极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。

极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了测试->编码->重构(设计)的软件开发管理思路。

极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。转自项目管理者联盟项目管理者联盟1、小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

2、规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。项目管理培训

3、现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。 bbs.mypm.net

4、隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。项目经理圈子转自项目管理者联盟5、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。

6、重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

7、测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。

8、持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。 blog.mypm.net

9、结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。 10、代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。

11、编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。

12、每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。

测试驱动开发

测试驱动开发（TDD）改变了编码的过程，并且这种改变不仅是可能的，同时也是值得去做的。开发包括三方面的活动：编写测试用例，编码并进行测试，重构代码以消除重复代码使其更简单、更灵活、更容易理解。

这个过程会频繁地重复，每次进行测试均是为了保证产品的正确性。设计、编码和测试三者之间的鸿沟将不再存在，这样可以促进你对整个环境更好地理解。因此，你的设计（和编码）将随着项目的成熟逐步得到改善而非降低。

使TDD更加有效的原因是单元测试自动化，而且这些自动化单元测试的工具可以从Internet上免费获得。虽然没有简化功能版的商业产品，但开发人员可以合理地使用这些高质量的软件。本文将指导你怎样获得和使用Nunit并通过C#（或者任意一种基于Microsoft .Net Framework的语言）开发实践TDD。注意到类似的工具对于C++和Java开发人员也是可用的，因为他们支持大多数语言和操作系统。这些工具与极限编程紧密地结合起来，扩大了TDD应用的范围。

为什么设计会降低性能

大多数传统软件开发过程是基于你在设计之初正确的设计与估计，并通过开发以形成完美的产品。这种开发方式保证了产品的统一性和之间的最小差异。然而这一过程却忽略了交流与反馈，同时也不利于生成错误信息（测试失败），并因此制定策略采取相应的措施（修复设计），而这些正是TDD所重视的。

为什么我们不能在开始就获得正确的设计？因为在开发时，处于项目之初的我们无法获得有关这个软件完整的知识。迭代式开发虽然也认同这一事实，并帮助你在项目开发初期识别一些重要的问题，而不是把这些问题留在后期解决。然而，迭代法无法终止开发过程，使你回到设计阶段来解决问题，哪怕这只是因为一个命名糟糕的公共类名。没有人愿意关注这些细小的问题，且不幸地，这种设计过程也禁止这种更新，因为在各个阶段不停重复的代价太高。

传统开发过程中的这些小问题一旦积累起来，会导致大问题的发生。你或许认为与其将时间耗费在这些对功能影响不大的细枝末节上，还不如将精力放在更重要的环节。然而，这个命名糟糕的公共类在代码中保留的时间越久，则相关的使用也会越来越多，改变起来就越来越困难。之后，团队会在编码的时候非正式地修改这些问题，很快，在计划发布整个产品时，你会做大量的工作尽量使代码和设计文档保持一致。对于这种情况来说，你之前的设计是没有价值的，因为代码本身就说明了设计。

测试驱动开发允许你推迟决定，直到你更好地理解了问题之所在。当你只是了解到产品开发的一些基本信息时，你不必设计出完美的体系架构。这对于传统软件开发中已经确定的理念来说，是一种挑战，从某种角度来说，甚至是违反常规的。因此我们建议你以一种开放的思想来尝试TDD，你会发现TDD的强大。

TDD的另一个好处是更容易掌握。你开发的一系列测试说明了代码的运行机制，这种程序自我编档的方式促进了交流。它要求你通过概览测试用例并阅读自己的代码来获得反馈，从而有利于你创建的对象和组件更趋于松散耦合。同时，TDD可以推迟你的设计决策，从而简化设计，使你能集中精力修正设计的问题。最后，它通过给出的一系列测试减轻你编码的压力，因为当测试发生中断时，它可以立即告诉你究竟发生了什么。

简介

要真正理解TDD，唯一的办法就是实践。让我们从一个简单的例子开始，这个例子并不要求任何特殊的工具。我们要写一个小程序，来帮助我们规划住宅前的一块长方形的草坪，但在设计之初，我们需要作两个测试：当长度为3，宽度为2时，计算得到的面积应该为6；同时计算其周长应该为10。

写下这些测试有助于我们将焦点集中到程序的一些要点。在这个例子中，似乎创建一个对象来模拟问题域是合理的，因此我们创建了一个类，取名为Quad，来代表我们要建造的长方形草坪，并在一个简单的控制台应用程序中实例化它。下面就是我们实现的步骤：
1、启动桌面的Visual Studio，选择文件 | 新建 | 项目，选择C#项目类型中的“控制台应用程序”。为项目取名为“QuadApp”，然后点击OK。
2、在主函数中输入下列几行代码，创建Quad实例，并通过Assert断言，当长宽各为3和2时，返回的结果应该是6。
static void Main(string[] args)
{
     Quad q = new Quad();
     System.Diagnostics.Debug.Assert(q.Area(3,2) == 6);
}
3、选择项目 | 添加类，在对话框中输入“Quad.cs”，点击“打开”以创建类。
4、输入下列代码，创建在Main函数中用到的Quad类的成员方法Area：
public class Quad
{
     public int Area(int length, int width)
     {
         return 0;
     }
}
5、选择生成 | 生成QuadApp 菜单项，此时编译应该是成功的，然后当你运行该程序时，会报告错误，因为此时返回的面积值不等于6。
6、指定Area方法的返回值为6，再重新编译程序，并运行，此时没有错误发生。
7、改变Area方法的实现，返回值用输入参数的乘积来代替起初指定的返回值常量。再次重新编译程序，并运行测试。

第二个测试（计算周长为10），与前面的方法相似。首先在主函数中通过assert写测试代码，接着执行第4到第7步，只是方法名用Perimeter而不是Area。当你在第七步中试图改变设计时，你可能会得出一个结果，就是可以通过构造函数来传递长和高的值，并将其存储为对象的属性，而不是通过成员方法的参数来传递。设计改变后的代码如下：
public class Quad
{
private int m_length;
private int m_width;

    public Quad( int length, int width)
    {
        m_length = length;
        m_width = width;
    }
    public int Area()
    {
        return m_length * m_width;
    }
}

重新编译程序，并运行之，以保证你在写代码是否因粗心而漏掉了什么。

我们通过一种最简单的形式完成了演示TDD工作原理的练习。下面是每一步的总结：
1、写一个失败的测试：我们选择了一个最容易实现的测试（虽然在这个例子中所有的都很简单）来实现。接下来，我们写了个Quad类的最简单实现，以保证程序能够通过编译。然而，当我们执行程序时，调试窗口会出现assert的错误信息，因为返回的面积值不是6。
2、修改代码以通过测试：要修改代码，首先我们做一个最简单的方法，就是直接返回常量值6。该值刚好使程序能够运行且通过测试。接着下一个测试必须使用不同的参数值，迫使我们实现正确的算法，以通过所有的测试，即使我们还没有开始下一个环节的重构。
3、重构代码：既然在我们的程序中达到了正确的预期目的，我们应该试图去掉一些重复代码使代码更易维护，更简单，更灵活，也更易于理解。我们可以发现这种改变在运行测试时，并没有影响到程序的行为。

修改代码使其易于维护，要求不能修改程序可观察的行为，这个思想并不是全新的理念。然而这里重要的是通过重构，而不是一遍一遍地整理代码。重构必须是软件开发活动中一个关键的环节，通过合适的工具，并采取系统的方法，可以逐步地改善代码的质量。通过执行贯穿于产品整个生命周期的许多次小的重构，最后达致最完美的目标，从而使得软件易于维护。

倘若必要的反馈要求你的设计（和代码）在产品开发中得到改进，则重构是测试驱动开发中不可缺少的步骤。当然你也可以不执行TDD方式，而进行重构以去除重复代码，使其更简单、灵活、更易于理解。无论你采取什么开发方式，你都需要将重构作为一种常规的活动，以保证你的更改是有效的。

重构的力量在于其能够减少因为改变正在工作的代码所带来的危险。好的工具能够帮助你减少潜在的危险，而同等重要的是要采取一系列严谨的步骤和正确的结构与规则。Martin Fowler的大作《重构：改善既有代码的设计》对于重构有非常精彩的描述。他定义了一系列非常有用的重构模式，并提供许多相关的样例指导你怎样进行重构。

目前，Visual Studio.Net除了提供查找和替换功能外，对重构没有太多的支持。然而，相信在不远的将来MS会提供更多有力的工具，使你能完成更多复杂的工作，例如符号的重命名，在编译-生成级上更改类名，而不是在你的源文件中作替换操作。你甚至可以期待这样一天的到来——当你选中一段代码后，通过Visual Studio提供的菜单，直接应用重构模式，然后继续下一步工作。你有充足的信心保证你的程序是更加易于维护的，而不会引入bugs或者会改变其可观察的行为。

经验总结

迄今为止，你应该明白一条最重要的道理就是TDD很简单。事实上，TDD能帮助你更好地理解任意一门新的语言、新的技术和组件。通过TDD，你可以决定将要采取的步伐的跨度。有经验的专家可以采取大的步伐，以避免中间环节。一旦发现开发有误，可以令过程回滚，采取更小的步伐重复前面的过程。关于TDD我们需注意下列事项：
1、测试使代码文档化（The tests document the code）。从测试的类Quad中可以清晰地看到这点；
2、随着测试的进行，我们可以把握进度。通过测试，可以验证每个功能是否正确，如此每个人都可以运行测试来了解过程是否如我们说期望的那样被良好的建立。
3、测试让人对代码的修改充满信心。即使你是一个C#的新手，也可以象专家那样老练的编程，运行所有的测试确保你所做的没有违反既定的规则。
4、类似于“将长度和宽度以参数的形式传递给面积和周长，而非在构造函数里指定”这样的错误，可以通过重构来修正。
5、当你将TDD应用到现实世界时，你可以生成许多测试，并通过如Nunit的工具来组织它们。

使用Nunit使测试自动化

TDD可能会生成成千上万个测试。假使项目中的每一个人都在周而复始地重复“写测试，修改代码，重构”，当然有必要使你的测试工作更加有效。如Nunit这样的测试框架就是设计用来帮助你提高效率的利器。它允许你象在Visual Studio中建立项目的方式，将你的测试用例装载到NUnit中，以合理地安排各自的项目。你可以将所有测试用例以层次结构显示出来，以单用例或测试包（一组测试用例）的方式运行测试，观察执行后的结果是成功（显示绿色进度条）还是失败（显示红色进度条），同时还将显示每次失败的详细信息。

图一：NUnit中的测试状态

另外，NUnit还提供了一些特殊的方法，使你能够在测试包开始和完成时执行初始化（initialize）和清除（clean up）被不同的测试用例所共享的“测试套件（test fixtures）（例如：长文件，数据库连接，公共链接）”。你也可以定义Setup和TearDown方法使其分别在执行测试前和完成后运行。它可以帮助你通过重新更改每个用例间的系统设置，使特定的用例从其它用例中独立出来。

Nunit允许你用与应用程序相同的语言和环境来写测试用例。不需要学习特定的测试语言，使开发测试迅速而直接。同时还有一个完整的Assert类提供特定用例失败后的详细信息。

最后，NUnit还可以作为控制台应用程序运行，只需要通过命令方式就可以输出结果。支持自动化创建合法的进程，举例来说，这样你就可以重建应用程序，并运行完整的测试包。同时，NUnit控制台应用程序还可以生成Xml格式的测试结果日志。

有着软件测试背景的人们应该能认识到这些特性的价值，但即使你不具备这些经验，也能清楚地明白它能为作为开发人员的你做出多大的贡献。不过，不管你是专家还是新手，要明白NUnit是怎样帮助你组织测试用例的，最好的办法还是实践。你可以到http://www.nunit.org/去下载NUnit。关于使用该软件的详细细节可以从其许可文件中获得。

本文使用的NUnit是2.1 beta版，你也可以去下载最新版本的MSI文件（大约1.5MB）。有了这个文件后，你可以双击它进行Windows下的安装。它可以在.Net Framework1.0和1.1版本下运行，当然你也可以参考NUnit文档获得有关系统需求的更多信息。

安装好后，选择“Test”的子菜单项运行你的测试包，以确保产品是否安装正确。单击了菜单项后，等待你桌面上的NUnit打开后，然后单击“Run”按钮。

不到一分钟的时间，treeview下的所有节点都将显示为绿色，这表明测试正常执行并通过。测试运行的数目会在状态条中显示出来，同时会显示执行测试所花的时间以及失败用例的数目。有时候你可能会得到一些显示为红色的节点，这表明测试失败，你可能需要重新安装NUnit，或者从NUnit.org站点获得建议。

在NUnit中使用测试用例

NUnit有一些附带样例，你可以使用他们其中的样例，如Money项目，来学习使用NUnit的开发流程。

在你的桌面上启动Visual Studio，选择文件 | 打开 | 项目菜单，在NUnit的安装目录（Program Files\NUnit）的子目录src\samples\money下找到Money.csproj文件，单击“打开”按钮并等待Visual Studio将其加载。在解决方案资源管理器窗口中，查看引用文件夹中nunit.framework引用是否正确。选择Build | Build Money编译Money项目。编译应该成功通过，没有错误和警告。

在桌面上启动NUnit。Treeview中应该是空的——如果不是，请选择File | Close菜单关闭所有已存在的项目。然后在File菜单中选择Open菜单项打开Money.csproj文件，就像你在Visual Studio中打开该文件一样。现在Treeview中应该包含测试样例的集合。

选择Treeview（文件Money.csproj）中的根节点，单击NUnit右侧的“Run”按钮。测试用例的所有包均被执行，并恰好获得一个失败的测试——MoneyBag Equals。

选择MoneyBag Equals测试用例（红色的叶结点），并定位到该文件的出错行，此时NUnit的右侧下方会显示相关信息，如图二：

图二：NUnit错误跟踪

切换到Visual Studio，打开该文件并定位到出错行。将该行注释掉（在行开始处插入//）并重新编译（生成 | 重新生成Money），此时编译将完全通过，没有错误和警告。

现在再切换到NUnit，注意到Treeview的所有节点均为灰色，这表明你更新后的程序还没有运行。选择Treeview的根节点，单击“Run”按钮。你可以看到所有的测试均通过且没有错误。

以上就是NUnit的全部工作方法。现在可以为你自己的项目创建测试用例了。

测试用例

测试用例定义了一系列输入，同时也可以定义一系列输出，以验证被执行的某些程序特性没有引入任何Bug。测试可能会失败是因为产品里有Bug，但也可能是测试代码自身有Bug——可以称为false negative。相似的，测试能通过也有可能恰好是因为测试中有Bug，而非你的产品准确无误，我们称为false positive。[译注：意思是测试中有Bug，而产品中也有Bug,巧的是这两处的Bug恰好负负得正，抵消了Bug所带来的影响，反而使测试通过。]好的测试应该避免出现false negatives，且绝对不能包含false positives。另外，好的测试包不仅要测试正确的场景，也要测试错误的用例。

测试对象和其环境在测试用例被执行前总是保持相同的状态，因此一旦有必要就需重复执行并给出恒定的结果。当测试失败时，定位到错误的地方就能获得相关的信息。通过这些信息就能推断出问题能否被纠正。这就是为什么要求你对每个测试用例都要验证其合法性的原因所在。

现在我们为Quad例子写一些测试用例来实践上述的原理。在Visual Studio和NUnit中打开Quad项目，和起初打开Money项目的方法一样——选择文件 | 打开菜单，并定位到QuadApp.csproj。选择项目 | 添加引用，找到文件nunit.framework.dll（在NUnit安装目录的bin子目录下），单击确定，添加引用nunit.framework。

在Visual Studio中创建QuadTest类：选择项目 | 添加类，输入名字QuadTest.cs，然后单击“打开”。输入下列代码到QuadTest中：
using System;
using NUnit.Framework;

namespace QuadApp
{
    [TestFixture]
    public class QuadTest
    {
        [TestFixtureSetUp]
        public void DoTestSuiteSetUp()
        {
            Console.WriteLine("TestSuiteSetUp");
        }
        [TestFixtureTearDown]
        public void DoTestSuiteTearDown()
        {
            Console.WriteLine("TestSuiteTearDown");
        }
        [TearDown]
        public void DoTestCaseTearDown()
        {
            Console.WriteLine("TestCaseTearDown");
        }
        [SetUp]
        public void DoTestCaseSetup()
        {
            Console.WriteLine("TestCaseSetup");
        }
        [Test]
        public void Area()
        {
            Quad q = new Quad();
            Assert.IsTrue( q.Area(2, 3) == 6);
            Console.WriteLine("Area");
        }
        [Test]
        public void Perimeter()
        {
            Quad q = new Quad();
            Assert.IsTrue( q.Perimeter(2, 3) == 10);
            Console.WriteLine("Perimeter");
        }
    }
}

编译后，在NUnit中运行测试。单击NUnit右侧的Console.Out标签，可以查看执行的顺序。

现在你可以看到，不同的Setup和TearDown方法是怎样允许你控制测试环境，从而保证你的测试用例能根据需要而重复执行并给出恒定的结果。这些方法将帮助你确保运行一个测试用例而不会影响到另外的用例（测试用例独立性test case isolation）。测试独立性的最佳证明就是具备以任意顺序运行测试用例的能力。试着改变一下测试用例的顺序，以确认他们是否具有独立性。

测试套件和测试包

一个测试套件是一个或多个测试用例共享的一个对象，这些测试用例都与测试对象的初始化或提供相应资源有关。在NUnit的术语中，测试套件是一个具备特性（attribute）[TestFixture]的类，并提供下列方法：
1、[Test]方法形成不同的测试用例。这些测试样例应该是测试的核心操作，并且与其它测试无关。
2、[SetUp]和[TearDown]方法提供测试用例间的环境设置。它们分别在测试开始前和结束后执行。
3、[TestFixtureSetUp]和[TestFixtureTearDown]方法要求对象被测试用例共享。它们分别在测试套件开始和结束时执行。

你希望运行测试的任意对象都可以在[TestFixture]类（被所有测试用例共享）里创建实例变量，也可以在方法（对于单个测试用例中是私有的）中创建局部变量，这就是为什么要描述为测试套件（test fixture）的原因。然而，你也可以将NUnit的[TestFixture]看作是组织测试包的一种方法，它将测试包组织为每个类，形成treeview的每一个分支。

既然你已经能够为自己的项目创建测试包，并且通过NUnit来运行它们，那么就让我们开始TDD之旅吧。当然，首先还要看看我们在开发工作中可能会遇到的问题。

在现实世界中使用TDD

在使用TDD时，首先要考虑的是：既然商业产品是设计用来组织你的程序的，那么产品代码就应该很容易从代码中分离出来，以用来测试。在产品开发期间，你可以运行你的测试程序，而为了发布产品，你仍然能够轻易地将其从代码中移除。

你可能会遇到的另一个难题就是测试GUI应用程序的困难，因为GUI应用程序是被鼠标和键盘输入而驱动的。举例来说，你应该怎样写测试程序来激活用户点击dropdown list控件的事件呢？如果用户选择的是国名列表，那么又该怎样验证选中的内容呢？

解决这些问题的方案就是：将代码根据编译、测试和部署分类为不同的组件。举例来说，我们不应创建一个作为主应用程序的Quad类，生成相同的可执行文件；而应该允许这个类能够被包含在一个单独的库文件（.dll）中。[译注：实质就是将Quad以类库的形式创建，而非应用程序。] 这样我们就可以开发单独的测试程序和域程序作为各自的可执行文件（.exe），并共享同一个包含Quad类的公共库文件（.dll）。注意，如果你仅仅创建了库，NUnit和你的测试包会被当作接口使用，而不是所需的单独的业务外观（separate harness）。

记住这个原则：“使主程序尽量简单，而将复杂的业务作为类放到库中”。它将帮助你解决测试GUI应用程序的问题。TDD的其中一个原则就是你不能测试第三方代码，因此你没有必要测试GUI框架类，虽然当框架相对简单的时候，有时会用来测试接口。这意味着你可以捕捉类里的用户事件，因为你知道这个类是怎么工作的；然后再将其传递到类里进行处理。此外，你也可以将测试程序和域程序从单独的可执行文件中分离出来，而该执行文件则共享了你竭尽心力开发的公共库。

让我们看看怎样实际运用TDD来开发包含有Combobox控件的简单窗体应用程序。

开发一个测试和创建库

在Visual Studio里选择文件|新建|项目菜单新建一个控制台应用程序，取名为CountryTest。然后如第一个例子那样，为项目添加nunit.framework引用。选择项目|添加类菜单，输入名字CountryBoxTest.cs，点击“打开”按钮，创建类CountryBoxTest。然后在CountryBoxTest类中输入下列代码：
[TestFixture]
public class CountryBoxTest
{
    [Test]
    public void CheckContent()
    {
        CountryLib.CountryList list = new CountryLib.CountryList();

        Assert.AreEqual("UK", list.GetCountry(1));
        Assert.AreEqual("US", list.GetCountry(2));
        Assert.AreEqual("CH", list.GetCountry(3));
        Assert.AreEqual(null, list.GetCountry(4));
    }
}

生成项目。编译失败，因为CountryList类不存在。

使用Visual Strudio，选择文件|新建|项目（添加到业已存在的解决方案中），创建一个新的类库，命名为CountryLib。选择项目|添加类输入名字CountryList.cs，单击“打开”，创建新类CountryList。然后将下面的代码输入到CountryList中，并编译。
public class CountryList
{
    public String GetCountry(int No)
    {
        return null;
    }
}

首先我们为项目添加引用CountryLib.dll，然后重新编译控制台应用程序CountryTest。此时项目运行正常，因为我们已经创建了CountryList类。

在NUnit中打开CountryTest.csproj，并运行测试。显示失败，因为CountryList.GetCountry方法返回null。切换到Visual Studio，在类CountryList中修改GetCountry方法，使其返回测试所需要的值——仅仅添加一些字符串常量，如下所示：
public class CountryList
{
    string ne = "UK";
    string two = "US";
    string three = "CH";

    public string GetCountry(int No)
    {
        if ( No == 1 )
            return one;
        if ( No == 2 )
            return two;
        if ( No == 3 )
            return three;
        else
            return null;
    }
}

这段代码主要是为了程序正常进行，而写的最简单的例子。重新编译CountryList类库，并切换到NUnit，然后运行测试——运行成功。

对CountryList进行你认为必要的重构，每次重构后都进行测试，以检查是否出现错误。你可能认为在ArrayList中存储字符串可以使代码更简单，容易，更利于理解，同时避免重复，但是你也可以选择其它解决方案。

创建GUI

使用Visual Studio选择文件|新建|项目（添加到现有的解决方案中）创建新的Windows应用程序，并为项目添加引用CountryList.dll。接下来，在工具栏中拖动combobox控件到主窗体上。然后将下面的代码输入到CountryApp中，并编译应用程序。
private void InitializeComponent()
{
...
CountryLib.CountryList list = new CountryLib.CountryList();

String country;
int index = 1;

while ((country = list.GetCountry(index++)) != null)
this.comboBox1.Items.Add(country);

...
}

现在你的项目已经有了基本的结构，它允许你采用TDD技术通过进一步开发CountryList类库来创建GUI应用程序。考虑一下CountryList怎样才能处理用户接口事件（鼠标单击，键盘），并通过这个方法使其能够被CountryTest测试，并被CountryApp使用。对于CountryList，你可能会有比本文的示例更好的解决方案，不过本示例试图说明：测试驱动开发能够改善设计，即使设计已经成熟。之前你不必一定要拿出完美的设计方案，这对于开发人员来说，无疑是一个福音。

结论

大多数设计都是从上而下创建，并基于可观察的特性进行分类，促进对问题的理解和解决。换句话说，我们试图创建层次结构的对象，它模型化了问题域。相反，TDD则是从下而上，通过对一些小问题，依次实施一系列简单的解决方案，最后演进为设计。

重构确保了设计集中于一个好的解决方案而不是逐渐脱离设计。如果你认为这是设计之根本，你就对了。TDD将在这十年潜在地改变软件开发的方法，就像过去十年面向对象技术所做到的那样。

NUnit提示：当我们使用Visual Studio打开NUnit附带的预先建好的测试样例时，你可能会发现引用nunit.framework.dll显示未找到，那么请打开解决方案资源管理器窗口的引用文件夹。此时你需要删除已经存在的引用（选择文件，右击“移除”），然后再次添加（选择引用，右击“添加引用”，浏览并定位到该文件，单击“确定”）。nunit.framework.dll文件可以在NUnit安装文件夹的bin子目录下找到。

本文链接

我是如何学习设计模式的五：代理模式和装饰模式的关系-引出装饰模式-下一节讲解装饰模式

2012-04-20T04:24:00Z

代理模式和装饰模式的关系

装饰模式: 动态的对一个对象进行功能上的扩展，也可以对其子类进行功能上的扩展。

代理也是对真实对象功能扩展,让功能类可以专注与自己的功能,至于怎么被试用的,即辅助工作完全由代理来处理

本文链接

我是如何学习设计模式的九：轻松一下，学习一个简单的：单例模式（最简单，但是也是最有用的）

2012-04-20T04:23:00Z

我故意把单例模式放在中间讲解，因为其原理简单，但是作用是最大的，让大家轻松点，轻松点的目的是为下一个超级重要的模式做准备：工厂模式，本人将把世界有关工厂模式的一切易学的资料吃透，整理给大家阅读，学习！

单例模式

理论

C#单例模式的三种写法

原文：http://blog.sina.com.cn/s/blog_4b8589b70100c5mt.html

第一种最简单，但没有考虑线程安全，在多线程时可能会出问题，不过俺从没看过出错的现象，表鄙视我……

public class Singleton

{

private static Singleton _instance = null;

private Singleton(){}

public static Singleton CreateInstance()

{

if(_instance == null)

{

_instance = new Singleton();

}

return _instance;

}

第二种考虑了线程安全，不过有点烦，但绝对是正规写法，经典的一叉

public class Singleton

{

private volatile static Singleton _instance = null;

private static readonly object lockHelper = new object();

private Singleton(){}

public static Singleton CreateInstance()

{

if(_instance == null)

{

lock(lockHelper)

{

if(_instance == null)

_instance = new Singleton();

}

return _instance;

}

第三种可能是C#这样的高级语言特有的，实在懒得出奇

public class Singleton

{

private Singleton(){}

public static readonly Singleton instance = new Singleton();

}

哦，shit！

创建一个单体模式类，必须符合三个条件：

1：私有构造函数（防止其他对象创建实例）；

2：一个单体类型的私有变量；

3：静态全局获取接口

下面我写一个类，为了看是不是单体，就加了一个计数器，如果是同一个类，那么这个类的计数每次调用以后就应该自动加一，而不是重新建对象归零：

.NET c# 单体模式

using System;

using System.Threading;

public class Singleton{

private int ObjCount=0;

private Singleton(){

Console.WriteLine("创建对象");

}

private static Singleton objInstance = null;

public static Singleton getInstance() {

if (objInstance==null) objInstance=new Singleton();

return objInstance;

}

public void ShowCount(){

ObjCount++;

Console.WriteLine("单个对象被调用了{0}次",ObjCount);

}

};

然后我们来测试一下：

public class ConsoleTest{

public static void Main(string[] args){

Console.WriteLine("开始执行单体模式");

for(int i=0;i<5;i++){

Singleton.getInstance().ShowCount();

}

Console.ReadLine();

}

};

我在这个Main里面执行了5次，看看输出的结果：

开始执行单体模式

创建对象

单个对象被调用了1次

单个对象被调用了2次

单个对象被调用了3次

单个对象被调用了4次

单个对象被调用了5次

在这里可以看出，每次都是使用的同一个对象，实现了单体。

为了测试在多线程下面是否是单体，下面我写了一个多线程测试的：

class ApartmentTest

{

public static void RunMoreThread()

{

Thread newThread = new Thread(new ThreadStart(ThreadSingleMethod));

newThread.SetApartmentState(ApartmentState.MTA);

Console.WriteLine("ThreadState: {0}, ApartmentState: {1},ManagedThreadId:{2}", newThread.ThreadState, newThread.GetApartmentState(),newThread.ManagedThreadId );

newThread.Start();

}

public static void ThreadSingleMethod() {

Singleton.getInstance().ShowCount();

}

};

然后每次for循环执行ApartmentTest.RunMoreThread();

再看看输出的结果：开始执行单体模式

ThreadState: Unstarted, ApartmentState: MTA,ManagedThreadId:3

创建对象

单个对象被调用了1次

ThreadState: Unstarted, ApartmentState: MTA,ManagedThreadId:4

单个对象被调用了2次

ThreadState: Unstarted, ApartmentState: MTA,ManagedThreadId:5

单个对象被调用了3次

ThreadState: Unstarted, ApartmentState: MTA,ManagedThreadId:6

单个对象被调用了4次

ThreadState: Unstarted, ApartmentState: MTA,ManagedThreadId:7

单个对象被调用了5次

根据ManagedThreadId，可以看出不同的线路访问达到了单体，OK！

c#的单体模式介绍完毕；

本文来自: 脚本之家(www.jb51.net) 详细出处参考：http://www.jb51.net/article/13117.htm

单例模式有以下的特点：

1 :单例类只可有一个实例。

2 :单例类必须自己创建自己这惟一的实例。

3 :单例类必须给所有其他对象提供这一实例。

一般创建单例我们常用的有两种方式:

1:静态变量法,也叫惰性实例化

2:双重锁定

静态变量法非常好理解,.net的运行机制决定了静态变量可以形成单件,静态变量是一个存储在内存中的变量.它的机制可以保证同一时间只会存在一个变量.为此我们非常容易的可以写出这样的程序:

Code

非线程安全的单件#region 非线程安全的单件

/**//// <SUMMARY>

/// 定义自身的静态变量实例,默认值为null

/// </SUMMARY>

private static Singleton instance = null;

/**//// <SUMMARY>

/// 私有构造函数

/// 之所有不是public类型的,因为是为了避免发生new Singleton()产生更多的实例

/// </SUMMARY>

private Singleton()

{ }

/**//// <SUMMARY>

/// 生成实例方法

/// </SUMMARY>

/// <RETURNS></RETURNS>

public static Singleton getInstance()

{

//如果实例没有被初始化则实例化变量

if (instance == null)

{

instance = new Singleton();

}

return instance;

}

#endregion

这种对于单线程运行的程序来说是绝对没有问题的,例如运行一个asp.net程序,一般网站都基本用不到多线程,所有上面的例子就足够满足.但是如果是多线程呢?如果同时有两个线开始判断instance==null,如果此时都为真,则创建了两上实例,这样就违背了单件的原则.为此可进行下修改:

Code

线程安全的单件(静态变量方法)#region 线程安全的单件(静态变量方法)

/**//// <SUMMARY>

/// 定义自身的静态变量实例,在程序运行时初始化变量

/// instance被申请成readonly,也是为了避免给实例重新赋值.

/// </SUMMARY>

private static readonly Singleton instance = new Singleton();

/**//// <SUMMARY>

/// 私有构造函数

/// 之所有不是public类型的,因为是为了避免发生new Singleton()产生更多的实例

/// </SUMMARY>

private Singleton()

{ }

/**//// <SUMMARY>

/// 生成实例方法

/// </SUMMARY>

/// <RETURNS></RETURNS>

public static Singleton getInstance()

{

return instance;

}

#endregion

这种方法在程序初始化时对类实例进行了初始化,利用静态变量以及私有构造方法完成了单件的生成.之所以称这种方式是惰性实例化,是因为,无论你是否调用这个实例,它都会被创建.

双重锁定:

我们可以对方法1进行下改造,它的缺点就是非线程安全,既然有缺点当然就要改正了.

Code

线程安全的单件(双重锁定方法1:线程安全但性能较差)#region 线程安全的单件(双重锁定方法1:线程安全但性能较差)

/**//// <SUMMARY>

/// 定义自身的静态变量实例,默认值为null

/// </SUMMARY>

private static Singleton instance = null;

/**//// <SUMMARY>

/// 创建一个object对象,同样它也是静态只读,用来实现锁定功能

/// </SUMMARY>

private static readonly object olock = new object();

/**//// <SUMMARY>

/// 私有构造函数

/// 之所有不是public类型的,因为是为了避免发生new Singleton()产生更多的实例

/// </SUMMARY>

private Singleton()

{ }

/**//// <SUMMARY>

/// 生成实例方法

/// </SUMMARY>

/// <RETURNS></RETURNS>

public static Singleton getInstance()

{

//取得实例的时候先锁定对象,然后判定是否存在

lock (olock)

{

//如果实例没有被初始化则实例化变量

if (instance == null)

{

instance = new Singleton();

}

return instance;

}

#endregion

这个方法是线程式安全的单件模式,但是它每次生成单件的时候都要给对象加锁,这样也是一种性能消耗.上面说了有缺点就要改,这个方法当然也不例外:

Code

线程安全的单件(双重锁定方法2:线程安全而且性能优越)#region 线程安全的单件(双重锁定方法2:线程安全而且性能优越)

/**//// <SUMMARY>

/// 定义自身的静态变量实例,默认值为null

/// instance被申请成readonly,也是为了避免给实例重新赋值.

/// </SUMMARY>

private static Singleton instance = null;

/**//// <SUMMARY>

/// 创建一个object对象,同样它也是静态只读,用来实现锁定功能

/// </SUMMARY>

private static readonly object olock = new object();

/**//// <SUMMARY>

/// 私有构造函数

/// 之所有不是public类型的,因为是为了避免发生new Singleton()产生更多的实例

/// </SUMMARY>

private Singleton()

{ }

/**//// <SUMMARY>

/// 生成实例方法

/// </SUMMARY>

/// <RETURNS></RETURNS>

public static Singleton getInstance()

{

if (instance == null)

{

//取得实例的时候先锁定对象,然后判定是否存在

lock (olock)

{

//如果实例没有被初始化则实例化变量

if (instance == null)

{

instance = new Singleton();

}

return instance;

}

#endregion

这个方法在生成的实例的时候,先判断是否为空,如果不为空则不对对象进行加锁操作直接返回对象实例.同时这种双重锁定对比静态方法来看,有一个优势就是它的实例化延迟到类中,只有调用此类的实例时它才会生成实例.

上面都是常规的单件模式,其实并不是所有的情况都如上面一样.在抽象工厂的应用中经常结合单件模式来应用,使得工厂实例是唯一的.在上一篇用抽象工厂模式武装新闻组件中,我用上了抽象工厂,当时在抽象工厂类实例的生成上并没有结合单件模式,所在在这想改造一下.我的程序思路是这样的,有一个抽象工厂基类AbstractFactoryClass,它包含一个public static AbstractFactoryClass GetInstance()方法,作用是生成它的派生类的实例,而这个生成过程是通过反射来完成的.这两个派生类分别是:AbstractFactory_China,AbstractFactory_US.这种情况下要想直接返回AbstractFactoryClass的实例是不可能的,因为它是抽象类,不能直接new AbstractFactoryClass().

先看下这三个类的类图:

代码如下:

Code

//把抽象类设置成静态变量,避免多次加载程序集

private static AbstractFactoryClass instance=null ;

/**//// <SUMMARY>

/// 创建一个object对象,同样它也是静态只读,用来实现锁定功能

/// </SUMMARY>

private static readonly object olock = new object();

public static AbstractFactoryClass GetInstance()

{

//应用双重锁定来产生工厂单件对象

if (instance == null)

{

lock (olock)

{

if (instance == null)

{

//取得当前工厂名称

string factoryName = ConfigurationSettings.AppSettings["factoryName"].ToString();

if (factoryName != "")

instance = (AbstractFactoryClass)Assembly.Load("AbstractFactoryCompent").CreateInstance(factoryName);

else

instance = null;

}

return instance;

}

上面的代码因为基类是抽象类所有没有上面常规程序中的私有构造函数,这种生成抽象工厂类派生类实例的案例并不适用于静态方法构造单件的情况,因为你不能直接通过new的方式来初始化类实例.

应用场景

在.NET框架的重要组成部分Remoting中，远程对象（Remote Object）有两种激活方式：服务器端激活方式和客户端激活方式。采用服务器端激活方式的对象又分为两种类型：Singleton对象和SingleCall对象。Singleton 对象是这样的对象：无论该对象有多少个客户端调用，它总是只有一个实例，由这个实例来处理所有的客户端请求。相反地，若将远程对象声明为 SingleCall，则系统会为每次客户端方法的调用创建一个新对象，即使这些方法调用来自同一个客户端，也即，对象只在方法调用持续期间存在，一旦方法调用结束，该对象就会被销毁。显而易见，这里的Singleton对象就是设计模式Singleton思想在.NET中的应用

　我们现在要做一个网络游戏的服务端程序，需要考虑怎么样才能承载大量的用户。在做WEB程序的时候有各种负载均衡的方案，不管是通过硬件实现还是软件实现，基本的思想就是有一个统一的入口，然后由它来分配用户到各个服务器上去。

泛型写的单例例子

Singleton

using System;

using System.Collections.Generic;

using System.Text;

namespace Pattern.Singleton

{

/**//// <summary>

/// 泛型实现单例模式

/// </summary>

/// <typeparam name="T">需要实现单例的类</typeparam>

public class Singleton<T> where T : new()

{

/**//// <summary>

/// 返回类的实例

/// </summary>

public static T Instance

{

get { return SingletonCreator.instance; }

}

class SingletonCreator

{

internal static readonly T instance = new T();

}

本文链接

我是如何学习设计模式的七:中介者模式—和command模式,观察者模式有一定关系

2012-04-20T03:57:00Z

中介者模式定义

中介者作为唯一知道其他类中方法细节的一个类，在类发生变化时通知中介者，中介者在将这些变化传递给其他需要通知的类

中介者模式的效果：

1 当一个类的动作要受另一个类的状态影响时，中介者模式可以防止这些类变得混乱

2 使用中介者很容易修改一个程序的行为。

3 可以添加新的控件或类，除了改变中介者外，不用改动任何部分。

4 中介者解决了每个command对象要对用户接口中的其他对象和方法了解太多的问题

5 中介者变成了一个万能类，知道太多其他部分程序的信息，这会使他难以修改和维护。

6 每个中介者都是一个指定的类，要拥有的每个同事要调用方法，并知道每个同事有哪些可用的方法，这使得在不同项目中重用中介者变得很困难。

Mediator中介者模式定义:
用一个中介对象来封装一系列关于对象交互行为.

为何使用Mediator?
各个对象之间的交互操作非常多;每个对象的行为操作都依赖彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性.

如何使用?

首先有一个接口,用来定义成员对象之间的交互联系方式:

public interface Mediator { }

Meiator具体实现,真正实现交互操作的内容:

public class ConcreteMediator implements Mediator {

//假设当前有两个成员.
private ConcreteColleague1 colleague1 = new ConcreteColleague1();
private ConcreteColleague2 colleague2 = new ConcreteColleague2();

...

}

再看看另外一个参与者:成员,因为是交互行为,都需要双方提供一些共同接口,这种要求在Visitor Observer等模式中都是相同的.

public class Colleague {
private Mediator mediator;
public Mediator getMediator() {
return mediator;
}

public void setMediator( Mediator mediator ) {
this.mediator = mediator;
}
}

public class ConcreteColleague1 { }

public class ConcreteColleague2 { }

每个成员都必须知道Mediator,并且和 Mediator联系,而不是和其他成员联系.

至此,Mediator模式框架完成,可以发现Mediator模式规定不是很多,大体框架也比较简单,但实际使用起来就非常灵活.

Mediator模式在事件驱动类应用中比较多,例如界面设计GUI.;聊天,消息传递等,在聊天应用中,需要有一个MessageMediator,专门负责request/reponse之间任务的调节.

MVC是J2EE的一个基本模式,View Controller是一种Mediator,它是Jsp和服务器上应用程序间的Mediator.

将一些对象的相关功能集合在一格类中。乍看之下和单件模式没什么不同。深入看看模式的定义，才发现中介者模式的集合含义是不同的：单件模式是将相关的功能集合在某一类中，供给许多类使用，但这些类之间是没什么关系的。
　
中介者模式是将需要交互的类的交互功能合并在某个类中，这个类充当中介。也可以看成调度。这样做是为了降低类之间的耦合，中介者类也能充当一个交互的层或某些适配功能。
　
比如，我们有一个流程驱动，其中的某一个状态需要提交到下一操作。这时，是在状态类中派生使用下一个状态/操作类？还是提交给流程驱动类，由他来进行提交的处理呢？因为可能状态提交会带来某些额外的操作，或者流程是用户运行时决定的，这时当前状态是不知道下一状态是什么，就无法进行有效的编码。
　
或者，在某一个GUI中，某些成员（某个按钮，列表等）的变化将会影响到许多其他的成员，这时使用观察者模式将会比较复杂（可能是N*M），编码成本会比较高，又没有复用的可能，就可以考虑使用中介者模式了。

中介模式的组成部分

中介者模式的组成部分吧。

1) 抽象中介者（Mediator）角色：抽象中介者角色定义统一的接口用于各同事角色之间的通信。

2) 具体中介者（Concrete Mediator）角色：具体中介者角色通过协调各同事角色实现协作行为。为此它要知道并引用各个同事角色。

3) 同事（Colleague）角色：每一个同事角色都知道对应的具体中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。

通俗的例子

1婚姻介绍所

Mediator模式的概念Mediator模式是行为模式之一，Mediator模式定义一个对象来封装对象的交互行为。从而降低对象间的耦合程度。

在Mediator模式中，类之间的交互行为被统一放在Mediator的对象中，对象通过Mediator对象同其他对象交互，Mediator对象起着控制器的作用。

Mediator模式的应用场景与利点当多个类之间相互依存，互相调用，关系过于复杂时，可以考虑使用Mediator模式来简化它们之间的关系。

使用Mediator模式时的优点

1，将系统按功能分割成更小的对象，符合类的最小设计原则

2，对关联对象的集中控制

3，减小类的耦合程度，明确类之间的相互关系：当类之间的关系过于复杂时，其中任何一个类的修改都会影响到其他类，不符合类的设计的开闭原则，而Mediator模式将原来相互依存的多对多的类之间的关系简化为Mediator控制类与其他关联类的一对多的关系，当其中一个类修改时，可以对其他关联类不产生影响（即使有修改，也集中在Mediator控制类）。

4，有利于提高类的重用性

Mediator模式的应用范例下面，我们使用Mediator模式模拟男孩女孩找对象的行为：在Boy类中，需要调用Girl类的方法；相反，在Girl类中，也需要调用Boy类的方法。所以我们采用Mediator模式来实现这个过程。

文件一览：

Client

测试类

Mediator

Mediator中介者类，这里省略了抽象类

Person

关联类（Boy, Girl）的抽象类。关联类之间并不一定需要共享一个父类，这里为了方便，为他们抽象出一个Person类

Boy

关联类之Boy，跟Girl类相关联

Girl

关联类之Girl，跟Boy类相关联

代码：

public class Client {

/**

* Test Mediator Pattern

public static void main(String[] args) {

//婚姻中介所开张了

Mediator mediator = new Mediator();

//一个名为Zhangshan的男孩，条件为80

Boy zhangshan = new Boy(mediator, "Zhangshan", 80);

Girl lili = new Girl(mediator, "Lili", 80);

//如果条件符合，则partner成立

zhangshan.findPartner(lili);

//一个名为lanlan的女孩，条件为90

Girl lanlan = new Girl(mediator, "lanlan", 90);

lanlan.findPartner(zhangshan);

}

/**

* 关联类（Boy, Girl）的抽象类

* 关联类之间并不一定需要共享一个父类，这里为了方便，为他们抽象出一个Person类

abstract class Person {

//姓名

String name;

//条件

int condition;

//中介者（不管男孩还是女孩，都需要知道中介者，通过中介者去找对象）

Mediator mediator;

public Person(Mediator mediator, String name, int condition) {

this.mediator = mediator;

this.name = name;

this.condition = condition;

}

public abstract boolean findPartner(Person person);

public int getCondition() {

return condition;

}

public void setCondition(int condition) {

this.condition = condition;

}

public String getName() {

return name;

本文链接

个人第一次踏进软件开发-辛苦，失望中寻找希望，这是我以前的日志

2012-04-20T03:22:00Z

某一天

坚持服从原则，还应注意对部领导的决议、指示不能因自己有不同意见而不执行。正确的态度是一方面积极向部领导反映自己的意见，另一方面在部领导没有采纳自己的意见修改决议指示之前，仍要按原指示决议执行，在执行中积极采取措施，把可能造成的损失减少到最低程度。当然，执行的结果证明部领导指示是错误的，责任由部领导承担。

　搞好工作，力争显著的政绩，这是大家的共同愿望，作为部领导，总是希望下属出色地完成各项任务，成为自己的得力助手和骨干。因此，积极努力地做好工作，尽职尽责，为部领导分忧解难，是组工干部处理好与部领导关系的一条重要原则。

第二天：

人的一生短短数十载, 虽然我比他们晚熟很多,但是我感觉我的人生太短暂了.

想起过去的往事,今晚默然很伤感,虽然多少次告诉自己 ,可是感觉一点用都没有.

从今天开始 ,只做自己,开心过好每一天,不要表现给谁看;记住，自己说过的话：一年之内不要上QQ,不要上校内网,不要玩任何游戏。

如果成熟就意味着失去快乐,我愿意忍住一切,忍住寂寞,我要长大,我要实现霸业!

好好学习工作,一定要成长起来,一定要成为一个男人.

第三天

今天晚上和自己的同事一起吃了一次饭.

我挺开心的.

晚上回到家 , 好想打开 QQ 打开校内网 ,写一写自己的心情.

不过我没有打开 ,我一定要牢记自己这次自己说出来的话.

校内, qq 绝对不打开 ,努力去控制自己 ,多学习,少玩,一心一意工作!

要记住:

工作第一,

服从领导第一,

提高自己的技能第一,

勤奋第一,

时间第一,时间第一,时间第一,时间第一,时间第一,时间第一,记住自己曾经说过的话,记住:用终生来偿还曾经浪费的时光

友谊第一,

诚信第一,

做人第一,

自控能力第一,

不忘过去发生的事情,以及从中学习到的经验教训,

时时告诉自己:我不是一个小孩子了,成熟但不乏幽默!

表面精明,"坏" 但切记要胸怀正义之心!

自己目前有太多的不会,编程要靠大量的试验去提高自己的经验.

虚心学习,请教.

不做最聪明的人,只做最勤奋的人!

珍惜时间

当然 MSN 因为工作需要~~~

1踏踏实实老老实实做人,

2年轻人有时候就会冲动 ,切忌在自己冲到的时候或者突发想做什么事情的时候 ,要控制自己,三思而后行.

3早上人人都喜欢睡懒觉,当自己睡意很浓的时候,一定要告诉自己,立即起床!

4晚上好好在公司学习,尽量少做些和工作学习无关的事情!

5珍惜拥有的工作,同事,朋友,领导......好好工作,不为功名,钱财,利禄,而尔虞我诈,珍惜拥有,用勤奋,时间,奋斗去对待...

实现自己的人生价值才是硬道理....

6 真心对待每一个人,不管发生什么事情,不管为了什么, 都不要牺牲任何人的利益,不要使得身边的人因为你而受到伤害!

7有时候说话总是不准,或者让人听了不是自己想表达的意思 ,有时候还可能造成误会,这个时候一定要停一下,好好组织语句

不要慌张,不要一着急就为自己的话圆话,要随机应变心平气和去好好的解释.

8 多沉默 ,少说话,多做事,多学习,能不说就不说,不要在工作的时间和同事开玩笑,浪费时间,一心一意工作!

9自己有时候总是控制不好而贪玩或者一玩就好几天, 搞的自己天天感觉浪费了这么的时间.所以切忌当自己玩的念头很大的时候,

一定要控制自己,有时候很大很大的时候,要好好的好好的三思,切忌不可再学以前浪费这么时间去玩游戏.

10 有些事情控制不好就不要去接触,比如游戏只要是游戏就不要去接触 ,一丝一毫都不要接触,不管它被人描述的有多好玩,

看别人玩的有多开心,不管自己事业到什么地步,都不要接触游戏,赌博,烟....没遇到事情,或者新鲜事物之前,要分析一下,这个对自己

工作学习有没有帮助 .学会分析.

尤其要警惕社会上的新鲜事物,或者自己新知道的事物,最近发生的事情,都要静下来想想: 怎么样处理这个新鲜事物才能更好

的促进自己工作学习 .

如果新鲜事情好, 但是对自己的学习帮助不是太大,亦不接触.

不管遇到好的,坏的,大的,小的都要先想一想,因为刚开始接触的东西不知道他的好坏而错误的判断,冷静冷静冷静....

多观察,,,,,,

11好的休息好的身体才能在工作中发挥创新灵感.....所以一定要好好休息 ,生物钟要注意,不可以凭借一时冲动 ,兴头

而通宵达旦搞的第二天精神不好,影响工作,影响工作必定会影响心情

12对于技术,能不问的就不问,自己钻研,请教别人要谦虚要有三顾茅庐之心.

13 记住自己曾经的经历,不要刻意追求太高,不要好高骛远,不要心高气傲

14切忌不要表现出任何不成熟的动作,不管是别人夸你,贬你,骂你,不管在什么场合,不管别人喜欢的是什么,都要成熟稳重.

即使你认为你应该表现的......切忌不要.时刻成熟稳重,不管什么情况下.

18请教别人问题要提前组织好,不问傻瓜的问题不问可以查到的问题,要虚心一点,

知足而乐

19 好人 .以后不要说自己是一个好人, 好人这两个我还配不上,好人对于我来说意味很多,

我不是好人,但是我会学习那些好人,我想做一个好人!

第四天

今天又说错话了,学会承担错误不管是自己的还是别人的.

不要怕别人说你不好 .

讲清楚就可以了

第五天：

今天又说错了一句话.

不要紧张.

不要夸大化,实事求是.

第六天

我是K2华北地区的销售,欢迎您和我联系.

Mobile:13520537854

Mail:song@k2.com

本贴来自ZDNetChina中文社区 http://bbs.zdnet.com.cn ,本贴地址：http://forums.cweek.com.cn/viewthread.php?tid=212696

jiweiyu@hongzhi-tech.com

陆俊杰 :

想寻觅一份在上海的工作

3年asp.net工作经验

13801790374

superpopredboy@gmail.com

k2学习的一个群 5326881

第八天：明天晚上的计划

以后要早点睡觉不要熬夜不然影响白天的效率切忌

明天开始制定自己的生活计划学习计划

jquery 学习

json学习

并尽可能多的用在自己的项目上

gridview 等各种控件的实战学习

dataview学习

页面传值用在自己的程序中

jquery json 用在自己开发的程序中

在自己开发的程序中多用线程正则表达式多用ajax技术这个当做主流技术

主要奋斗方向网页 bs架构

试着在页面用设计模式一边学习一边用

晚上学习白天把晚上学习到的东西用在项目的开发中

多用存储过程触发器事务索引多写 sql 语句,

sql函数用在项目的开发中

如果是小型的数据库可以用xml去写学会去处理xml 可以试着用在自己的项目中

开发同步异步线程的程序加锁解锁

看看自己编写的程序中有没有读者写者的问题临界资源的问题都可以用线程做

学习模板主题的应用应用在自己开发的项目中

多开发一些小的用户控件一些公用的东西写成用户控件

要学会用JavaScript来布局

每天不要学习太多而是要思考如何更好的用在我们开发的项目中比如线程

可以考虑那些地方可以用到线程每天力求学到的东西可以在实践开发中用到

第九天

永远记住,要时刻准备着,锻炼自己,磨练自己,勤奋学习,向成功迈进!

第十天：自己需要改进的地方

事情没有做好就积极去承担 ,想方法去解决,don't say anything ,keep quiet, just do until completing it!

要让自己积极一点,不管别人说你什么,都不要因为别人的话而着急 ,放松点,越着急越做不好!

一定要学会多问,不明白就问,不要一直稀里糊涂的做事情,所以一定要问明白,不要在乎别人说你笨蛋,说你水平不高而怕问,勇敢的承认自己就是笨蛋,不要在错误的方向下钻研.

不管将来有多么成功都不要因为一时的成功而骄傲,而乱说话.

比如继伟布置的添加 try catch 语句既然不知道在那里加就问,不要怕别人说你笨蛋而不好意思去问.

永远记住这是一个团队的项目,程序出错项目经理问是谁改错的,不要说这个一定不是我 ,这样会给人的感觉你团队意识不强.

不要看不起别人,别人有值得你学习的地方就不要看不起别人,不管是谁 ,多说谢谢两字!

以后不要解释任何东西 ,即使别人误会也好,错了就是错了,勇敢的说出来,少说话,默默地去改正.

自己的毛病: 就是说话的时候有时候因为心急或者别人误会你,或者自己没有做好一件事情会因为心急而说出一些让人认为是不好听的话,虽然你不是这样想的.但是,别人怎么知道呢,谁叫你说话的水平这么差的.

任何时候说话之前要心平气和,在自己写错程序遭到上级领导批评的时候尤其要注意不要为自己辩护,不要怕被批评,不要总是认为自己委屈,要多想想自己那里需要改进让自己做到无一丝漏洞.

不要自大要承认自己是个笨蛋,不要和别人争论,不要推卸责任,大家一起做的程序,有错就不要怪谁,不要为了推卸责任而说一些丧气或者推卸责任的话.

项目经理指出的错误需要修改的地方用笔记下来,不要为自己辩解即使别人冤枉你, 修改好就可以

一定要学会承受被别人冤枉而依旧心平气和不要去恨不要泄气 ,不说丧气话,不说难,不叹气,最重要的是闭嘴.

以后只说三句话 : 项目经理指出你的错误 .你的做法: 拿起笔记下来. 然后只说一句话: 恩 .记下来了我会好好改正的.不管有多少错误都不要害怕去承担勇敢去看待自己写错的不管是因为业务不清楚错还是因为粗心还是因为什么都不要去计较不要给自己理由要好好去修改 .

如果别人要是又写错的代码不要说别人的不对,不要说这个我帮你改了不要说这个是不是你做的, 能自己帮助改正确的自己该不能再请教要当成是自己的工作是自己不会该去请教

加入项目经理问你做好了吗你得问答没有,还没有改好或者恩好了 ,

其他任何话都不要说不要辩解不管别人说什么都沉默

以后从基础的开始学起,多做 ,以实践为主.

每天都要有计划!

以后不管自己学会什么都要把自己当成笨蛋,别人夸你的时候, 你要说谢谢 ,然后说 , 不,我还很多东西要学,或者我比较笨吧谢谢大家指教

问过之后要说谢谢, 谢谢不要离口

总之说话前要想以精简为主~~~

别人说你不好要对别人说谢谢指出我的缺点

以后要积极去约束自己,从点点滴滴做起 , 努力做好自己,

培养自己,时刻注意自己从小事情做起.

本文链接

我是如何学习设计模式的六：装饰模式

2012-04-20T03:10:00Z

模式四:装饰模式

理论

装饰模式（Decorator）也叫包装器模式（Wrapper）。以“装饰”的含义生动形象地描绘了“动态地给一个对象添加一些额外的职责”的意图。GOF在《设计模式》一书中给出的定义为：动态地给一个对象添加一些额外的职责。装饰模式充分利用了继承和聚合的优势，创造出无与论比的设计美学。就增加功能来说，Decorator模式相比生成子类更为灵活。

　从面向对象的角度来说，我们要为一个对象添加一新的职责完全可以利用继承机制来实现，但是这样的设计会导致一个问题，“过度地使用继承来扩展对象的功能”由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着字类的增多(扩展功能的增多)，各种子类的组合(扩展功能的组合)会导致更多子类的膨胀，也就是所谓的类爆炸。如何使“对象功能的扩展”能够根据需要来动态地实现同时又避免“扩展功能的增加”带来的类爆炸问题？从而使得任何“功能扩展变化”所导致的影响将为最低？

装饰模式是在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。

装饰模式的特点；

（1）装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。

（2）装饰对象包含一个真实对象的索引（reference）

（3）装饰对象接受所有的来自客户端的请求。它把这些请求转发给真实的对象。

（4）装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展。

下表格列举了装饰模式和继承的不同：

装饰模式 VS 继承

装饰模式继承

用来扩展特定对象的功能用来扩展一类对象的功能

不需要子类需要子类

动态地静态地

运行时分配职责编译时分派职责

防止由于子类而导致的复杂和混乱导致很多子类产生，在一些场合，报漏类的层次

更多的灵活性缺乏灵活性

对于一个给定的对象，同时可能有不同的装饰对象，客户端可以通过它的需要选择合适的装饰对象发送消息。对于所有可能的联合，客户期望

很容易增加任何的困难

结构图

生活中的例子

装饰模式动态地给一个对象添加额外的职责。不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。

二、迎接Decorator的到来-例子1

例如我们要为一只“笔”来设计其行为。从我们拥有的面向对象的知识出发，为一个对象的原有方法添加新的职责，可以通过继承机制，从写基类方法来实现，此时父类方法应为虚方法或是抽象方法。

1namespace DesignPattern.Decorator
2{
3public class Pen
4{
5public virtual string Write()
6{
7return "普通的笔";　 //只能进行最基本的写操作
8}
9}
10}

如果我们需要为该笔添加新的职责，让其可以调整字体大小(这样的示例好象有点不符合现实哈，此处只是通过这个虚有的对象来演示Decorator，暂不考虑现实问题)，则可以定义一子类继承于Pen，然后重写Write方法。

1namespace DesignPattern.Decorator
2{
3
4public class BoldPen : Pen
5{
6public override string Write()
7{
8return base.Write() + FontSize();
9}
10
11private string FontSize()
12{
13return "字体大小：10px";
14}
15}
16} 以上的实际完全符合装饰模式的意图“不改变原有的行为动态地给一个对象添加一些新的功能”。想想，这样的设计美好吗？现在需求改变，要求这种笔出了能写之外同时还拥有可以设置字体大小及字体颜色的设置功能，按继承机制的思想来设计是不是应该继承BlodPen然后又重写Write方法呢？这样下去就形成了一个多子类的延伸的多重继承体系，最终出现的问题就是类无限的增多，既所谓的类爆炸。

三、重构Decorator的设计

要解决上述出现类爆炸的问题该怎么办呢？仔细观察就会发现，通过继承子类在添加新的职责的时候都需要重写Write方法才能实现，那我们是不是应该重构一下，抽象出共性呢？答案是肯定的，我们完全可以把Write方法抽象为接口或抽象类，通过抽象后我们可以通过聚合的方法动态的组合新的功能职责。重构后的设计如下：

　接口的抽象：

1namespace DesignPattern.Decorator
2{
3public interface IWrite
4{
5string Write();
6}
7}
8

Pen类的设计：

1namespace DesignPattern.Decorator
2{
3/**//// <summary>
4/// 实现IWrite接口
5/// </summary>
6public class Pen:IWrite
7{
8public string Write()
9{
10return "能写的笔";
11}
12}
13}
14

BoldPen类的设计：1namespace DesignPattern.Decorator
2{
3public class BoldPen:IWrite
4{
5IWrite component = null;
6int borderWidth = 0;
7
8public BoldPen() { }
9
10public BoldPen(IWrite compontent, int borderWidth)
11{
12this.component = compontent;
13this.borderWidth = borderWidth;
14}
15
16/**//// <summary>
17/// 接口方法
18/// </summary>
19public string Write()
20{
21//调用接口方法
22string pen = this.component.Write();
23return pen + " 字体大小：" + this.borderWidth.ToString();
24}
25
26/**//// <summary>
27/// 装饰方法
28/// </summary>
29/// <param name="borderWidth"></param>
30public void SetBorderWidth(int borderWidth)
31{
32this.borderWidth = borderWidth;
33}
34}
35}　

　如上的设计通过抽象出接口方法Write，不同的功能组件去继承实现IWrite接口实现Write方法，通过特定的属性或方法(我们可以叫它装饰方法)把自己的职责封装在自己的内部，这样的设计也完全符合面向对象的单一职责设计思想。

通过共性的抽象和一系列的新功能职责的装饰，新的设计应运而生，现在如果我们需要扩展出一种新的笔种，要求出了具备基本的写行为之外，还同时带有可设置字体大小和字体颜色的功能。显然，我们之前的设计就派上了用场，这时我们只需要通过聚合的方法就能够组合成这一种新的角色（笔种）出来。很明显应用了Decorator让设计变得更加灵活，同时也说明了一个问题，在我们实际的设计中，应少用继承多，尽量的通过聚合的方法来设计，提高设计灵活度。

通过组合设计出的新的笔种：

1namespace DesignPattern.Decorator
2{
3public class BoldColorPen:IWrite
4{
5private List<IWrite> list=null;
6public BoldColorPen()
7{ }
8
9public BoldColorPen(List<IWrite> list)
10{
11this.list = list;
12}
13public string Write()
14{
15string str = string.Empty;
16for (int i = 0; i < list.Count; i++)
17{
18str += ((IWrite)list[i]).Write() + " ";
19}
20return str;
21}
22
23private string Other()
24{
25　 //同样我们还可为其添加自己的职责

本文链接

Silverlight3发布大会演示作品-全国首例Silverlight企业级开发实例讲解4-我们是如何选择项目生命周期的

2012-04-20T03:01:00Z

概要：

1首先我会讲解软件工程领域项目生命周期的一些知识，

后面我会把我参考的资料给大家以链接或者下载的方法予

以提供！

2讲解项目管理中要考虑的元素：需求，时间，风险，人力，质量，技

术，配置，源代码等

3讲解我们是如何根据以上几个要素来决定我们项目最后采用了迭代式，敏

捷软件开发！

第一：软件生命周期

我主要将其分成三个部分:

软件生命周期概念

软件生命周期模型

软件生命周期方法

第一:软件生命周期的概念

概要:

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分

析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少

维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle

Model）。

　软件生命周期官方定义：

软件生命周期官方定义：

　软件生命周期(SDLC)的六个阶段

第二：软件生命周期模型（不要和软件生命周期混淆了哦）

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型

瀑布模型（Waterfall Model）（也可以理解为文档驱动模型）

瀑布模型
瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名型，自顶向下把一个软件开发过程分为：系统定义、需求分析、设计、编码、测试和维护等阶段。在开发过程中这些阶段顺序进行，就像是一个飞流直下的瀑布，因此得名。该模
型可以用下面的图形来表示。
        系统定义
          \|/
        需求分析
          \|/
         设计
          \|/
         编码
          \|/
         测试
          \|/
         维护
在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

瀑布模型下的测试环节：

，在瀑布模型的基础上，还衍生出了强调测试活动的V模型。它把瀑布模型的测试阶段

进行细分，并于前面的阶段进行对应。细分出来的这些阶段分别为：单元测试阶段、集成

测试阶段和系统测试阶段。V模型的结构图如下。

     系统定义                           维护
----------\------------------------------/------------

         需求分析       ..       系统测试
              \                      /
            概要设计    ..   集成测试
                 \               /
               详细设计    单元测试
                      \       /
                        编码

  系统测试（黑盒）：

与需求分析对应的是系统测试。因为需求分析的工作是分解用户的功能和性能需求并规
格化，所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现。
该测试把软件作为一个黑盒，针对每个需求规格组织各种输入并根据软件输出来判断该需
求规格是否正确实现，因此系统测试属于黑盒测试。

集成测试(灰盒)：

与概要设计对应的是集成测试。因为
概要设计的工作主要是根据功能把大的系统进行模块分解，所以集成测试的工作主要是，
把各模块逐步集成在一起，来测试数据是否能够在各模块间正确流动，以及各模块能否正
确同步。因为这种测试依赖于软件的架构但又不关心每个函数的实现细节，所以该测试又
常称为灰盒测试。

单元测试（白盒）：

与详细设计对应的是单元测试。它主要是详细设计中的每个功能单元（
通常是函数或过程）进行逻辑覆盖测试，因此这种测试属于白盒测试。与从需求到设计、
统测试，于是就形成了一个V字形的结构。
  与在瀑布模型中描述的一样，这些测试活动也是顺序进行的，并遵循一定的输入和输出
规则。

  瀑布模型的优点是清楚地标识出了软件开发的阶段。它采用自顶向下逐步求精的方式把
整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所
有的阶段都完成之后，该软件的开发过程也随之结束。
  瀑布模型的缺点正是它自身的顺序性所导致的。实际的开发过程中，在需求阶段很难把
用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、
设计、编码、测试等过程。
  实际的开发过程中，用得较多的就是瀑布/V模型，只是可以根据实际需要进行阶段合并
与裁减。

增量迭代式模型

迭代和增量模型
迭代：
迭代式模型是RUP推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围

元素。迭代的官方定义文绉绉的，通俗点说:就是把软件开发分成几个阶段，每个阶段都当作一个软件项目来对待，所以，在某种程度上，开发迭代是一次完整

地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认

为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

增量：

增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念.假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成.

RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一个可以交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需

求->设计->开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很大的关系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代.如果项目没有一个

很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.

迭代和瀑布的区别和优缺点对比：

迭代和瀑布的最大的差别就在于风险的暴露时间上。"任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。

不管开发团队经验如何，都绝不可能预知所有的风险。"（RUP）二者的区别如下图所示：

由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）

第三软件生命周期方法：

原型法
　原型法基本理论

原型法基本思想

原型法凭借着系统分析人员对用户要求的理解，在强有力的软件环境支持下，快速地给出一个实实在在的模型（或称原型、雏形），然

后与用户反复协商修改,最终形成实际系统

原型法（Prototyping）开发过程

首先用户提出开发要求，开发人员识别和归纳用户要求，根据识别、归纳结果，构造出一个原型（即程序模块），然后同用户一道评

价这个原型。如果不行，则再对原型进行修改，直到用户满意为止。

从原型向最终系统的转换

原型经过反复的使用、评价和修改以后，即可转入最终系统(或称正式系统)的开发，如图4-3-9所示。从原型向正式系统的转换方式有三种。

1.程序一次性使用(只利用需求和规格)

该方法对原型研制限定在传统软件生命周期的某一阶段，例如，需求定义阶段，正如我们在本章第3节所介绍的那样。该阶段工作结束

后，原型随之作废。该方式可用于验证、完善系统需求和人机接口的原型开发。

2．程序嵌入(作为核心部分利用)

程序嵌入方式是将完成了的原型体作为正式系统的核心部分。事实上这是一种附加策略，对应于我们在本章所介绍的演化型的开发形式，把原型作为核心，逐步添加新功能，发展成为最终系统。在抛弃策略中，原型与最终系统的开发可以采用不同的高级语言。而在附加策略中，因原型将作为最终系统的一部分，所以必须采用与最终系统相同的开发语言。

3.程序自动变换

采用该方法时，原型体用高级语言开发，并自动将原型体变换成比最终系统的语言更低的中间语言，使得嵌入在最终系统中的原型体

的运行效率比变换前大大提高。程序自动变换法尚存在一些未解决的问题，例如不同语言之间的自动变换的困难，后程序的性能不能保障

等。因此，该方法目前还处在研究阶段，并未达到实用化程度。

原型法优缺点和适用范围

原型法的使用范围

我们项目中的原型举例：

在silverlight开发中，因为我们只有开发人员，而没有设计人员，所以微软便推荐了一家设计公司（微软金牌合作伙伴）。
所以前期“三人帮”就出现了：客户，开发人员，设计公司共同合作来设计出前台界面。可以用 PS画出来，可以用PPT文档设计出来。
首先：客户提出需求（其实这个时候我们已经形成需求文档），大家共同讨论，刚开始一定要让设计人员自由发挥，不要限制他们的思维，当差不多了，然后再提出一些限制。当设计公司用PPT设计出相应的界面后（一般是三个版本，供客户选择），客户选择一个自己喜欢的，或者全盘否定，由设计公司重新设计，经过不断的协商，最后客户选定一款。
第二：客户选定一款后，这个时候只是确定了框架的整个外貌，然后还要针对其中的小细节继续商量，设计公司然后不断完善，最终达到客户的要求。然后设计公司根据PPT用xaml的矩形或者简单的东西组织出来，并且打到和PPT一样的效果。
第三：客户满意之后，然后是我们开发人员了，我们会提出一些技术难题，尽量让设计公司制作的前台能够降低我们的开发难度。
比如：
1设计公司原来给们设计的xaml，datagrid是用矩形堆积出来的，我们立刻要求他们在datagrid的基础上进行样式的制作，并且打到客户要求的水平。
2我们要求所有的空间全部用样式去做，并且要有一个样式的详细说明书。等等
下面是早期的一些我们开发人员提出的问题：

我们开发人员向设计公司提出的建议

1我们的项目中需要用到很多DataGrid控件, 你们提供的实例中批量数据的展示不是用DataGrid(GridVew)做出来的而是每一行放置一个Grid,Grid中再放置很多的TextBox控件堆积出来的,如果我们用DataGrid控件来实现这些功能,希望也可以很方便的引用你们事先定义好的样式,而我们只需要专心做如何与数据库交互.(如果实现复杂,可提供部分注释或说明文档,这样我们可以花较少的时间把样式引用到我们的项目中)

2  我们的菜单全部是根据权限从数据库中取出数据动态生成的,我们可能会在后台动态调用style 资源等信息 ,所以
应该把构成菜单的元素, 最好全部用 style 定义,这样我们在后台直接用代码调用.

3 动态生成菜单的方法:
第一种:首先在页面放置两个布局控件StackPanel(也可以是Canvas,Grid),一个用于承载一级菜单,一个用来承载二级菜单,然后动态往里面添加button
第二种:同样放置两个StackPanel,然后把一级和二级菜单子元素分别定义成一个控件,然后再用后台代码动态调用用户控件.

请问:你们还有什么更好的解决方案吗,既能动态生成菜单又能很方面的加载菜单上的动画效果,样式,资源,事件,数据.

4  对于经常用到的style 可以放在 APP.xaml文件中  最好稍微注释一下, 能够很容易辨别哪些样式是适用哪个控件的.

5 如果用theme(主题) 统一全局定义样式资源等信息也要按照不同的XAP包分别定义不同的theme文件.

6 最好将每一个模块对应的用户控件(页面),资源 ,图片等信息分别放在不同的文件夹中

7silverlight的精髓之一动画效果可用在菜单的显示上 ,尤其是方案设计这一块 ,一定要绚,精心打造! 动画都是事件驱动的,你们可以模拟点击一个button 出现动画效果, 由我们自行根据需要添加动画,你们添加的动画要能够方便我们移植到其他页面上

8 silverlight 全站开发 ,如何提高silverlight 性能可以让页面快速展示, 能不能给几点建议

如果频繁与数据库交互,json  ,WCF, ADO.NET EntityFrame, linq  WebClinet 等方式哪种速度最快而且较稳定

9动画效果样式效果要统一  ,尽量把一些公用的动画效果样式资源等放在单独的地方  然后用名字引用

10 如果用silverlight 3 开发页面的打开速度 ,与数据库交互的效率会不会有很大的提升,从而创造更好的用户体验.

11XAP 包一般多大比较好 ,拆分XAP包有没有好的建议 .

12 微软推荐的一些影响性能的效果比如隐藏可多用Visibility（可视性）而不使用 Opacity（不透明度）,在设计的时候可注意一下

13 你们设计的时候可能会用到一些特殊的字体 ,请问该如何将这些字体嵌入到silverlight开发工具中

第四：当三方都协商之后，设计公司根据要求设计出来前台（一般就是用基本控件堆积出来的）。

我们是用页面数量来计算资金的，为了达到降低成本，我们不可能要求设计公司设计每一个页面，而是挑出公共的。
这样设计出来的产品就是符合三方利益的原型。我们之后的开发都是基于这个设计开发的。

第五：需求人员和客户还要商量一些逻辑，就是点击某个button需要出现什么样的效果。也就是面向开发人员的用户操作手册。

这个操作手册按照需求模块来分类。分配任务的时候，方便开发人员查阅。
最后就形成了设计搞和操作手册。这个是我们开发人员开始开发的原型。

下面是部分设计demo和操作手册内容。

设计公司前台（PPT文档或者PS图形效果）：

设计公司XAML语言：

Code

也就是用一些简单的东西堆积出来。

用户操作手册：

以注册功能为例，看看根据设计公司demo形成的操作手册（图形来自设计公司的第一次设计的demo），也是我们开发人员参考的文档：

4. 注册
功能简介：
系统的用户主要分为三大类，（外网）企业用户、总部精算人员、各中心精算人员，其中总部精算人员和各中

心精算人员通过公司内部网络及内部登录系统来访问精算咨询系统；外网企业用户通过互联网登录首页，并注册成

为系统用户，才可以登录到系统。

操作流程：

1、点击[马上注册]，进入注册免责说明界面，如图：

2、勾选‘我已阅读并同意以上条填款’，点击[下一步]进入注册信息界面，填写完成后，点击[保存]，注册成功。如图:

5.    忘记密码
功能简介：
    如果用户忘记密码，可以通过此功能，通过正确回答注册时设置的问题的答案，重新设置新的密码。
操作流程：
1、    点击[忘记密码]，提示输入账户，如图：

2、    点击[下一步]，进入提示问题界面，如图：

3、    输入正确的问题答案后，点[下一步]，进入设定密码界面。
4、    两次输入密码后（两次输入的密码必须相同）点击[确定]，密码设置成功。

我们就是根据上面形成的原型进行开发的。

快速和敏捷开发

我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

关于选择生命周期模型的最后的总结

1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.

我们是如何进行需求管理的：

现实世界是在不断变化的，而且变化的速度是越来越快，IT领域唯一不变的就是“变化”。

一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。

项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

我们的需求管理：

1需求跟踪，定时更新。

2架构师，项目经理根据变化的需要讨论，分解，形成任务分配下去。

我们是如何进行进度管理的：

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 RUP或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。

我们是如何进行人员变更管理的：

人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而EAS项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。

风险管理

本文链接

Silverlight-MEF-DEMO-扩展计算机的功能

2010-10-15T09:56:00Z

“托管扩展性框架（Managed Extensibility Framework，简称MEF），是微软.NET框架下为提高应用和组件复用程度而推出的，用于使组件能够最大化的重用。使用MEF能够使静态编译的.NET应用程序转换为动态组合，这将是创建可扩展应用、可扩展框架和应用扩展的好途径。它将做为.NET Framework 4.0的组成部分之一发布。现在，MEF也将被包含在Silverlight 4.0中。

那么MEF是怎样工作的呢？简单分为三个步骤：

•Export （输出）
•Import （输入）
•Compose （组合）
简短说一下MEF的工作原理，MEF的核心包括一个catalog和一个CompositionContainer。category用于发现扩展，而container用于协调创建和梳理依赖性。每个可组合的Part提供了一个或多个Export，并且通常依赖于一个或多个外部提供的服务或Import。每个Part管理一个实例为应用程序运行。

下面我们做一个小型可扩展计算器示例来解释这三个过程

1.首先下载MEF框架包，Silverlight 4.0会自带，不过微软已经将其开源了。
http://www.codeplex.com/MEF
2.创建一个Silverlight Navigate Application ,并添加程序集引用(MEF_Beta_2\bin\SL目录下 System.ComponentModel.Composition.dll)
在项目下添加两个类文件Package.cs和PackageCatalog.cs，这两个文件在最新的MEF版本中没有提供，主要用于加载silverlight的Xap包。
这两个文件在MEF框架的Sample中提供了(MEF_Beta_2\Samples\PictureViewer\PictureViewer.Common)，将这两个类的访问修饰符改为public, 添加后注意修改命名空间。
3.修改Home.cs 类

代码

using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.ComponentModel.Composition;
using System.ComponentModel;

namespace MefDemo
{
//用于更新界面的委托
public delegate void OperateHandler(IOperate Op);

    /// <summary>
    /// 运算器接口
    /// </summary>
    public interface IOperate
    {
        double Op(double left, double right);
        string Symbol { set; get; }
        string Label { get; set; }
    }

    /// <summary>
    /// 加法运算器
    /// </summary>
    [Export(typeof(IOperate))]
    public class AddButton : Button, IOperate
    {
        [Import("AddButtonContract",AllowRecomposition = true)]
        public string Label { get { return this.Content.ToString(); } set { this.Content = value; } }

[Import("AddSybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left + right;
        }

#endregion

        public AddButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }

    /// <summary>
    /// 减法运算器
    /// </summary>
    [Export(typeof(IOperate))]
    public class SubButton : Button, IOperate
    {
        [Import("SubButtonContract",AllowRecomposition=true)]
        public string Label { get { return this.Content.ToString(); } set { this.Content = value; } }

[Import("SubSybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left - right;
        }

#endregion

        public SubButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }

    /// <summary>
    /// 为每个运算器的属性提供值
    /// </summary>
    public class ComponentAttributeProvider
    {
        [Export("AddButtonContract")]
        public string AddLabel { get { return "Add"; } }
        [Export("AddSybomContract")]
        public string AddSymbol { get { return "+"; } }
        [Export("SubButtonContract")]
        public string SubLabel { get { return "Sub"; } }
        [Export("SubSybomContract")]
        public string SubSymbol { get { return "-"; } }
    }
}
4.修改 Home.xaml

代码

<navigation:Page x:Class="MefDemo.Home"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
    mc:Ignorable="d" d:DesignWidth="640" d:DesignHeight="480"
    Title="Home"
    Style="{StaticResource PageStyle}">

    <navigation:Page.Resources>
        <ItemsPanelTemplate x:Key="ItemsPanelTemplate1">
            <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" VerticalAlignment="Center"/>
        </ItemsPanelTemplate>
    </navigation:Page.Resources>

</navigation:Page>

5.新建类 OperatorComponent.cs

代码

namespace MefDemo
{
//用于更新界面的委托
public delegate void OperateHandler(IOperate Op);

[Import("AddSybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left + right;
        }

#endregion

        public AddButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }

[Import("SubSybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left - right;
        }

#endregion

        public SubButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }

6.运行。这样就构建了一个简单的运算器，其中的Export、Import就像一个个管道一样相互连接。

7.按照这样的设计，我们想要对其进行扩展，就必须把接口分离。新建一个Silverlight ClassLibrary Project(Named ContractLibrary),这个Library用来封装所有的扩展接口，定义Import/Export契约。
现在把原项目中的OperatorComponent.cs 类中的接口迁移到Library项目中，新建类文件OperateContract.cs 。

代码

namespace ContractLibrary
{
public delegate void OperateHandler(IOperate Op);

    /// <summary>
    /// 运算器接口
    /// </summary>
    public interface IOperate
    {
        double Op(double left, double right);
        string Symbol { set; get; }
        string Label { get; set; }
    }
}
编译通过后在Silverlight主工程(MefDemo)中添加对ContractLibrary项目的引用
8.再新建一个Silverlight ClassLibrary Project (Named StaticExtension),，这个工程就是我们用来静态扩展的DLL。
a). 在工程下新建我们的运算器类，AddButton.cs , SubButton.cs.(代码不变).
b). 但注意要添加对ContractLibrary项目的引用和MEF的框架集引用) 。
c). 添加全局属性配置类(ComponentConfiguration.cs)
d). 删除主工程中的ComponetOperater.cs.
e). 添加对StaticExtension的引用.

9.OK,这样我们就可以任意扩展运算器，添加更多的扩展运算了。

10.那么下面是添加一个新的乘法运算所要做的工作。
在StaticExtension中添加新类 Multiply.cs

代码

namespace StaticExtension
{
    /// <summary>
    /// 乘法运算器
    /// </summary>
    [Export(typeof(IOperate))]
    public class MultiplyButton : Button, IOperate
    {
        [Import("MultiplyButtonContract", AllowRecomposition = true)]
        public string Label { get { return this.Content.ToString(); } set { this.Content = value; } }

[Import("MultiplySybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left * right;
        }

#endregion

        public MultiplyButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }
}

11.上面的是静态加载，那么现在我们使用MEF实现动态扩展运算器。桌面程序的动态扩展是动态加载DLL，而对于Silverlight的Web程序则是动态加载Xap包了。
新建普通Silverlight Application（Named DynamicExtension）.

去掉勾选Add a test page that references the application.
1). 删掉App和Main等不必要的文件，只留一个空的Silverlight项目，以减少Xap包的大小。
2). 添加ContractLibrary和MEF框架集的引用(可以将引用程序集属性CopyLocal设置为false，因为我们在主工程中已经添加了，可以重用)
3). 添加类Division.cs.

代码

namespace DynamicExtension
{
    /// <summary>
    /// 乘法运算器
    /// </summary>
    [Export(typeof(IOperate))]
    public class DivisionButton : Button, IOperate
    {
        [Import("DivisionButtonContract", AllowRecomposition = true)]
        public string Label { get { return this.Content.ToString(); } set { this.Content = value; } }

[Import("DivisionSybomContract", AllowRecomposition = true)]
public string Symbol { set; get; }

[Import("ClickHandler")]
public OperateHandler ClickAction { get; set; }

#region IOperate 成员

        public double Op(double left, double right)
        {
            return left * right;
        }

#endregion

        public DivisionButton()
        {
            this.Click += (s, e) => ClickAction(this);
        }
    }
}

4). 添加配置类ComponentConfiguration.cs

代码

namespace DynamicExtension
{
    /// <summary>
    /// 为每个运算器的属性配置值
    /// </summary>
    public class ComponentConfiguration
    {
        [Export("DivisionButtonContract")]
        public string AddLabel { get { return "Div"; } }
        [Export("DivisionSybomContract")]
        public string AddSymbol { get { return "/"; } }
    }
}

5). 修改Home.cs ，为其注册下载包的相关事件和回调

1.
代码

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Navigation;
using System.Collections.ObjectModel;
using System.ComponentModel.Composition.Hosting;
using System.Reflection;
using System.ComponentModel.Composition;
using ContractLibrary;

namespace MefDemo
{
    public partial class Home : Page
    {
        [ImportMany(typeof(IOperate),AllowRecomposition = true)]
        public ObservableCollection<IOperate> Operates = new ObservableCollection<IOperate>();

[Export("ClickHandler")]
public OperateHandler ClickHandler { get { return OperateButton_Click; } }

private PackageCatalog Catalog;

        /// <summary>
        /// 用于界面控件响应运算后的一些更新工作
        /// </summary>
        /// <param name="Operate">运算器</param>
        public void OperateButton_Click(IOperate Operate)
        {
            try
            {
                Symbol.Text = Operate.Symbol;
                double left = double.Parse(LeftNum.Text);
                double right = double.Parse(RightNum.Text);
                this.Result.Text = Operate.Op(left, right).ToString();
            }
            catch (Exception e)
            {
                ChildWindow errorWin = new ErrorWindow(e);
                errorWin.Show();
            }
        }

        public Home()
        {
            InitializeComponent();

            this.Loaded += new RoutedEventHandler(Home_Loaded);
            //注册按钮事件
            this.DynamicLoadButton.Click += (s, e) =>
            {
                //下载包
                Package.DownloadPackageAsync(
                    new Uri("DynamicExtension.xap", UriKind.Relative),
                    (args, package) => Catalog.AddPackage(package)
                );
                //包被添加到PackageCatalog后会自动重新组合
                //并对添加了AllowRecomposition = true属性的Import导入器重新输入数据
            };
        }

        void Home_Loaded(object sender, RoutedEventArgs e)
        {
            //组合当前XAP包中所有部件(Parts)
            Catalog = new PackageCatalog();
            Catalog.AddPackage(Package.Current);
            CompositionContainer container = new CompositionContainer(Catalog);
            container.ComposeParts(this);

            //组合后所有实现运算接口(IOperate)的运算器都将被自动填充到 Operates 集合。
            //将运算器绑定到 ListBox 控件，用于呈现。
            this.operateList.DataContext = Operates;
        }

        // Executes when the user navigates to this page.
        protected override void OnNavigatedTo(NavigationEventArgs e)
        {
        }

}
}

Ok，最终界面。

点击DynamicLoadOperate按钮后

程序中还有很多细节没有展开说明，理论性的介绍可以参考MSDN和CodePlex上的文档。

文章出处：飞诺网(www.firnow.com):http://dev.firnow.com/course/4_webprogram/asp.net/netjs/20100714/442928.html

本文链接

Silverlight按需加载--MEF方式--这篇文章简单,跟着做一遍再说--以后会翻译成中文

2010-10-15T08:54:00Z

MEF gives us the ability to do this. This post will cover the basics needed to build such a composite application split between different silerlight applications and download the referenced silverlight application only when needed.

Steps:

Create a Silverlight 4 application
Add references to the following assemblies:

System.ComponentModel.Composition.dll

System.ComponentModel.Composition.Initialization.dll

Add a new Silverlight 4 application called ExternalSilverlightApplication to the solution that was created in step 1. Ensure the new application is hosted in the web application for the solution and choose to not create a test page for the new application.
Delete the App.xaml and MainPage.xaml files – they aren’t needed.
Add references to the following assemblies in the ExternalSilverlightApplication project:

System.ComponentModel.Composition.dll

System.ComponentModel.Composition.Initialization.dll

Ensure the two references above have their Copy Local values set to false. As we will have these two assmblies in the original Silverlight application, we will have no need to include them in the built ExternalSilverlightApplication build.
Add a new user control called LeftControl to the ExternalSilverlightApplication project.
Replace the LayoutRoot Grid with the following xaml:

</Grid>

Add the following statement to the top of the LeftControl.xaml.cs file

using System.ComponentModel.Composition;

Add the following attribute to the LeftControl class

[Export(typeof(LeftControl))]

This attribute tells MEF that the type LeftControl will be exported – i.e. made available for other applications to import and compose into the application.

Add a new user control called RightControl to the ExternalSilverlightApplication project.
Replace the LayoutRoot Grid with the following xaml:

</Grid>

Add the following statement to the top of the RightControl.xaml.cs file

using System.ComponentModel.Composition;

Add the following attribute to the RightControl class

[Export(typeof(RightControl))]

In your original Silverlight project add a reference to the ExternalSilverlightApplication project.
Change the reference to the ExternalSilverlightApplication project to have it’s Copy Local value = false. This will ensure that the referenced ExternalSilverlightApplication Silverlight application is not included in the original Silverlight application package when it it built. The ExternalSilverlightApplication Silverlight application therefore has to be downloaded on demand by the original Silverlight application for it’s controls to be used.
In your original Silverlight project add the following xaml to the LayoutRoot Grid in MainPage.xaml:

<Grid.RowDefinitions>

</Grid.RowDefinitions>

</StackPanel>

The borders will hold the controls that will be downlaoded, imported and composed via MEF when the button is clicked.

Add the following statement to the top of the MainPage.xaml.cs file

using System.ComponentModel.Composition;

Add the following properties to the MainPage class:

[Import(typeof(LeftControl))]

public LeftControl LeftUserControl { get; set; }

[Import(typeof(RightControl))]

public RightControl RightUserControl { get; set; }

This defines properties accepting LeftControl and RightControl types. The attrributes are used to tell MEF the discovered type that should be applied to the property when composition occurs.

Add the following event handler for the button click to the MainPage.xaml.cs file:

private void Button_Click(object sender, RoutedEventArgs e)

{

DeploymentCatalog deploymentCatalog =

new DeploymentCatalog("ExternalSilverlightApplication.xap");

CompositionHost.Initialize(deploymentCatalog);

deploymentCatalog.DownloadCompleted += (s, i) =>

{

if (i.Error == null)

{

CompositionInitializer.SatisfyImports(this);

LeftContent.Child = LeftUserControl;

RightContent.Child = RightUserControl;

LoaderButton.IsEnabled = false;

}

};

deploymentCatalog.DownloadAsync();

}

This is where the magic happens! The deploymentCatalog object is pointed to the ExternalSilverlightApplication.xap file. It is then associated with the CompositionHost initialization. As the download will be asynchronous, an eventhandler is created for the DownloadCompleted event. The deploymentCatalog object is then told to start the asynchronous download.

The event handler that executes when the download is completed uses the CompositionInitializer.SatisfyImports() function to tell MEF to satisfy the Imports for the current class. It is at this point that the LeftUserControl and RightUserControl properties are initialized with composed objects from the downloaded ExternalSilverlightApplication.xap package.

Run the application click the Download External Controls button and see the controls defined in the ExternalSilverlightApplication application loaded into the original Silverlight application.

Congratulations! You have implemented download on demand capabilities for composite applications using the MEF DeploymentCatalog class. You are now able to segment your applications into separate xap file for deployment.

本文链接

Silverlight动态加载--MEF方法-

2010-10-15T07:45:00Z

.NET 4.0中提供了一个MEF框架用于开发支持插件的软件系统，幸运的是，Silverlight 4也支持MEF。这就使得我们可以很容易地实现以下的功能：

用户在访问Silverlight应用程序时，开始可以只显示一个“初始的简单的”页面，当用户需要时，动态从Web网站上下载新的程序集，然后，Silverlight客户端应用程序再使用MEF将动态下载的程序集中所包容的页面组件“组装”为一个新的功能增强了的页面。

示例解决方案DynamicComposePage展示了相关的技术细节。下面简要介绍一下其开发步骤。

1 使用Visual Studio 2010创建一个名为DynamicComposePage的 Silverlight Business Application项目。

Visual Studio 2010将会帮助我们创建一个名为DynamicComposePage.Web的ASP.NET网站，它引用名为DynamicComposePage的Silverlight项目。

在解决方案资源管理器中展开DynamicComposePage项目节点，在其Views文件夹下可以看到Visual Studio 2010生成的一个Home.xaml页面，等一会我们将修改此页面实现页面的动态装配。

2 现在需要提供一个MEF部件都遵循的接口，为此，向解决方案中添加一个“Silverlight类库（Silverlight Class Library）” 项目[1]MyPartContract，并向其中添加一个IMyPart接口，为简单起见，本例不为此接口添加任何成员，当然，在实际开发中可以依据需要为其添加合适的成员。

namespace MyPartContract
{
public interface IMyPart
{
}
}

复制代码

[1] 注意：这不是普通的“类库”项目，Silverlight所使用的程序集是重新编写的，与标准的.NET Framework不一样。

3 下面定义可供动态组合的Silverlight页面组件。

向示例解决方案中添加一个名为“MyPageParts”的“Silverlight类库（Silverlight Class Library）” 项目，注意在弹出的对话框中选择“Silverlight 4”。

然后，向MyPageParts项目中添加一个“Silverlight User Control”，取名“MyEditorControl”，在这个页面中我们将放置一个RichTextArea控件充当文字编辑器：

<UserControl x:Class="MyPageParts.MyEditor" ……>
<RichTextArea x:Name="MyEditorControl" …… />
</UserControl>

复制代码

现在，需要让此用户控件可以被MEF动态装配，为此，需要完成两个步骤：

（1）给本项目（也包括前面创建的Silverlight项目DynamicComposePage）都添加对包容了IMyPart接口的Silverlight类库MyPartContract的引用。

（2）给本项目（也包括前面创建的Silverlight项目DynamicComposePage）都添加对MEF核心程序集System.ComponentModel.Composition.dll的引用，将要负责完成“装配”工作的Silverligh项目DynamicComposePage还需要添加对另一个核心程序集System.ComponentModel.Composition.Initialization.dll的引用。

附件: Snap8.jpg

注意：

在以下位置才能找到上述程序集：

C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries

下面是支持MEF动态装配的Silverlight 4用户控件的相应代码，注意其中的“[Export]”标记：

[Export(typeof(IMyPart))]
public partial class MyEditor : UserControl,IMyPart
{
public MyEditor()
{
InitializeComponent();
}
}
源码http://cid-887e6220d1fad37c.office.live.com/self.aspx/silverlight/DynamicComposePage.rar

本文链接

博客园_王书奎(网名:无忌)

极限编程一 概述

我是如何学习设计模式的五：代理模式和装饰模式的关系-引出装饰模式-下一节讲解装饰模式

我是如何学习设计模式的九：轻松一下，学习一个简单的：单例模式（最简单，但是也是最有用的）

我是如何学习设计模式的七:中介者模式—和command模式,观察者模式有一定关系

个人第一次踏进软件开发-辛苦，失望中寻找希望，这是我以前的日志

我是如何学习设计模式的六：装饰模式

Silverlight3发布大会演示作品-全国首例Silverlight企业级开发实例讲解4-我们是如何选择项目生命周期的

Silverlight-MEF-DEMO-扩展计算机的功能

Silverlight按需加载--MEF方式--这篇文章简单,跟着做一遍再说--以后会翻译成中文

Silverlight动态加载--MEF方法-

极限编程一概述