rise51的专栏

<br />无废话C#设计模式之十：Flyweight<br /> <br />意图<br /> <br />       运用共享技术有效地支持大量细粒度的对象。<br /> <br />场景<br /> <br />在比较底层的系统或者框架级的软件系统中，通常存在大量细粒度的对象。即使细力度的对象，如果使用的数量级很高的话会占用很多资源。比如，游戏中可能会在无数个地方使用到模型数据，虽然从数量上来说模型对象会非常多，但是从本质上来说，不同的模型可能也就这么几个。<br />此时，我们可以引入享元模式来共

<br />无废话C#设计模式之三：Abstract Factory<br /> <br />意图<br /> <br />       提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。<br /> <br />场景<br /> <br />       还是上次说的那个网络游戏，定下来是一个休闲的FPS游戏。和CS差不多，8到16个玩家在游戏里面分成2组对战射击。现在要实现初始化场景的工作。要呈现一个三维物体一般两个元素是少不了的，一是这个物体的骨架，也就是模型，二就是这个骨架上填充的

<br />无废话C#设计模式之四：Factory Method<br /> <br />意图<br /> <br />       定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。<br /> <br />场景<br /> <br />       上次，我们使用抽象工厂解决了生产一组产品的问题，但是我们把各个场景作为了具体工厂来生产场景模式和场景纹理两个产品。在调用代码中也并没有出现具体工厂的影子。其实，场景类要做的不仅仅是创建具体的产品系列，可能它还需要做一个初始化工作。那么，我们就需要在

<br />无废话C#设计模式之五：Prototype<br /> <br />意图<br /> <br />       用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。<br /> <br />场景<br /> <br />       游戏场景中的有很多相似的敌人，它们的技能都一样，但是随着敌人出现的位置不同，这些人的能力不太一样。假设，我们现在需要把三个步兵组成一队，其中还有一个精英步兵，能力特别高。那么，你或许可以创建一个敌人抽象类，然后对于不同能力的步兵创建不同的子类。然后，使用

<br />无废话C#设计模式之七：Adapter<br /> <br />意图<br /> <br />       把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。<br /> <br />场景<br /> <br />       假设网络游戏的客户端程序分两部分。一部分是和服务端通讯的大厅部分，大厅部分提供的功能有道具购买、读取房间列表、创建房间以及启动游戏程序。另一部分就是游戏程序了，游戏程序和大厅程序虽然属于一个客户端，但是由不同的公司在

<br />无废话C#设计模式之八：Facade<br /> <br />意图<br /> <br />       为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。<br /> <br />场景<br /> <br />       在一个为游戏充值的网站中，创建订单需要与三个外部接口打交道：<br />l         用户系统：根据用户名获取用户ID、查看用户是否已经激活了游戏<br />l         卡系统：查看某种类型的充值卡

<br />无废话C#设计模式之十五：Strategy<br /> <br />意图<br /> <br />       定义一系列的算法，把它们一个一个封装起来，并且使它们可相互替换。本模式使得算法可以独立于它的客户而变化。<br /> <br />场景<br /> <br />       在开发程序的时候，我们经常会根据环境不同采取不同的算法对对象进行处理。比如，在一个新闻列表页面需要显示所有新闻，而在一个新闻搜索页面需要根据搜索关键词显示匹配的新闻。如果在新闻类内部有一个ShowData方法的话，

<br />无废话C#设计模式之十七：Chain Of Resp.<br /> <br />意图<br /> <br />       使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象能处理请求为止。<br /> <br />场景<br /> <br />假设我们在制作一个游戏的客服系统，客服有三种角色，分别是普通客服、客服经理和客服总监。玩家在网站中提问后，根据问题的分类和重要性处理的流程不一样。规则如下：<br />l 

Silverlight 学习笔记——MVVM模式实现主从数据显示 Posted on 2010-01-21 17:08 Saar 阅读(1430) 评论(24)编辑收藏<br />　　写本篇纯属意外。原来想用主从数据显示的例子记录页面间切换的方法的，后来在园子里看到有一篇写页面切换的文章介绍得很详尽了，代码做了一半，真是鸡肋啊。于是想，干脆把代码改改，弄成个MVVM模式来展示主从数据吧。<br />　　为了突出重点，示例不考虑美工方面的问题——嘿嘿，美工实在太差了，各位见谅。<br />　　首先来看完成后

初级： Head First Design Patterns、 .NET与设计模式 中级：敏捷软件开发 原则.模式与实践、道法自然、设计模式解析、 重构与模式、  高级：设计模式  《 可复用面向对象软件的基础》

<br />无废话C#设计模式之二十二：总结(针对GOF23)<br /> <br />比较<br /> <br /><br />设计模式<br />常用程度<br />适用层次<br />引入时机<br />结构复杂度<br />Abstract Factory<br />比较常用<br />应用级<br />设计时<br />比较复杂<br />Builder<br />一般<br />代码级<br />编码时<br />一般<br />Factory Method<br />很常用<br />代码级<

<br />无废话C#设计模式之十九：Observer<br /> <br />意图<br /> <br />       定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。<br /> <br />场景<br /> <br />这次不说游戏了，假设我们需要在一个Web页面上分页显示数据。首先需要一个分页控制器和一个显示数据的表格。开始，客户的需求很简单，需要两个向前翻页向后翻页的按钮作为控制器，还需要一个GridView来显示数据。你可能会这么做：<

<br />无废话C#设计模式之十八：Command<br /> <br />意图<br /> <br />       将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。<br /> <br />场景<br /> <br />       我们知道，网络游戏中的客户端需要不断把当前人物的信息发送到游戏服务端进行处理（计算合法性、保存状态到数据库等）。假设有这样一种需求，在服务端收到客户端的请求之后需要判断两次请求间隔是不是过短，如果过短的话就

<br />无废话C#设计模式之二：Singleton<br /> <br />意图<br /> <br />       保证一个类只有一个实例，并提供访问它的全局访问点。<br /> <br />场景<br /> <br />       我们现在要做一个网络游戏的服务端程序，需要考虑怎么样才能承载大量的用户。在做WEB程序的时候有各种负载均衡的方案，不管是通过硬件实现还是软件实现，基本的思想就是有一个统一的入口，然后由它来分配用户到各个服务器上去。<br />       需要考虑的问题是，即使在多线

<br />无废话C#设计模式之六：Builder<br /> <br />意图<br /> <br />       将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。<br /> <br />场景<br /> <br />       在电脑城装机总有这样的经历。我们到了店里，先会有一个销售人员来询问你希望装的机器是怎么样的配置，他会给你一些建议，最终会形成一张装机单。和客户确定了装机配置以后，他会把这张单字交给提货的人，由他来准备这些配件，准备完成后交给装机技术人员。技术人员会把这

<br />无废话C#设计模式之九：Proxy<br /> <br />意图<br /> <br />       为其他对象提供一种代理以控制对这个对象的访问。<br /> <br />场景<br /> <br />代理模式非常常用，大致的思想就是通过为对象加一个代理来降低对象的使用复杂度、或是提升对象使用的友好度、或是提高对象使用的效率。在现实生活中也有很多代理的角色，比如明星的经纪人，他就是一种代理，经纪人为明星处理很多对外的事情，目的是为了节省被代理对象也就是明星的时间。保险代理人帮助投保人办理保险

<br />无废话C#设计模式之十二：Bridge<br /> <br />意图<br /> <br />       将抽象部分与实现部分分离，使它们都可以独立的变化。<br /> <br />场景<br /> <br />还是说我们要做的网络游戏，多个场景需要扩充的问题我们已经采用了创建型模式来解决。现在的问题就是，不仅仅是游戏场景会不断扩充，而且游戏的模式也在不断扩充。比如，除了最基本的战斗模式之外，还会有道具模式，金币模式等。<br />对于这种在多个维度上都会有变化或扩充需求的项目来说，可以考虑引

<br />无废话C#设计模式之二十一：Visitor<br /> <br />意图<br /> <br />       实现通过统一的接口访问不同类型元素的操作，并且通过这个接口可以增加新的操作而不改变元素的类。<br /> <br />场景<br /> <br />想不出什么好例子，我们在组合模式的那个例子上进行修改吧。我们知道，无论是游戏大区、游戏服务器还是游戏的服务都是一个元素，只不过它们的层次不一样。对于这样的层次结构，我们使用了组合模式来统一各层的接口，这样对游戏大区的操作和对游戏服务器的操作

<br />无废话C#设计模式之一：开篇<br /> <br />什么是设计模式？<br /> <br />       什么是少林拳呢？少林拳是少林僧人经过长期的总结，得出的一套武功套路。有一本叫做少林拳法的武功秘籍，上面记载这这套拳法的适用人群，打法套路和学成后的效果。设计模式虽然记录在了设计模式一书上，但是要真正掌握设计模式光靠看每一个模式的结构并且进行模仿是不够的。试想一下，在真枪实战的情况下，谁会和你按照少林拳法，一二三四的套路打呢？打套路也只能用来看看，只有当你能根据不同的场景灵活出招的时候才能

<br />无废话C#设计模式之十一：Composite<br /> <br />意图<br /> <br />       将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。<br /> <br />场景<br /> <br />我们知道，一个网络游戏通常会有多个游戏大区。每一个游戏大区会有很多游戏服务器（一个游戏大区就是一组游戏服务器）。每一个游戏服务器上会有不同的服务（可以是多个服务）。这是一个明显的部分-整体关系，假设我们现在需要

<br />无废话C#设计模式之十四：Template Method<br /> <br />意图<br /> <br />       定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。<br /> <br />场景<br /> <br />模版方法是非常容易理解的设计模式，一来是因为它没有过多结构上的交错，二来是因为这种代码复用技术对于掌握OO知识的人来说非常容易可以想到，很可能你已经在很多地方运用了模版方

<br />无废话C#设计模式之十六：State<br /> <br />意图<br /> <br />       允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。<br /> <br />场景<br /> <br />       我们在制作一个网上书店的网站，用户在书店买了一定金额的书后可以升级为银会员、黄金会员，不同等级的会员购买书籍有不同的优惠。你可能会想到可以在User类的BuyBook方法中判断用户历史消费的金额来给用户不同的折扣，在GetUserLevel方法中根据用

设计模式（Design Patterns）                                   ——可复用面向对象软件的基础 设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化