Mikel

[转载]来源于WCF的设计模式：可扩展对象模式 – Artech – 博客园. 我一直很喜欢剖析微软一些产品、框架的底层实现。在我看来，这不但让我们可以更加深入地 了解其运作的原理，同时也能提高设计/架构的技能。因为对于这些框架或者产品来说，高质量的设计是它们能够成功的一个最基本的因素。比如说比如 ASP.NET，不但能够支持传统的Web Form应用，MVC同样建立在它基础之上。比如说WCF，从其诞生的那一天开始，真个架构体系就从未改变。这些应用在这些产品和框架上的设计其实是最值 得我们学习的设计案例。比如说，今天我们介绍的“可扩展对象模式（Extensible Object Pattern）”就来源于WCF。[源代码从这里下载] 一、一个简单的“可扩展对象模式”的实现 为 了让这种所谓的“可扩展对象模式”有一个大概的了解，我们先来演示一个简单的例子。现在有一个表示房间的类型Room，它具有几个基本的属性Walls、 Windows和Door分别表示房间的墙、窗户和门。现在我们要来创建一个Room对象，即分别创建组成这个Room对象的各个构成元素。按照“大事化 小”这个基本的设计原则，我们分别创建相应的Builder来分别为Room构建相应的元素。按照“可扩展对象模式”的原理，Room对象就是一个可扩展 对象，而相应的Builder实现了对它的扩展。现在我们将Room这个类型定义在实现了接口 IExtensibleObject<Room>的可扩展对象。 1: public class Room : IExtensibleObject<Room> 2: { 3: public Room() 4: { 5: this.Extensions = new ExtensionCollection<Room>(this); 6: } 7: public Door Door { get; set; } 8: public IList<Wall> Walls { get; set; } [...]

[转载]青梅煮酒论C#:Specification pattern – 空逸云 – 博客园. Specification模式早在3个多月前,阅读一个开源博客的时候便接触到了.但并没多少深入.最近,抽空将其好好研究了一番,果然,其魅力的确能让你回味无穷,那现在,就让我们零距离接触Specification模式吧! 何为Specification? Specification,中文有翻译规格,虽然有很多争论,但目前叫得最多的,还是规格模式,既然说到了规格,那其作用估计就能不言而喻了. Specification模式的作用是构建可以自由组装的业务逻辑元素. 上 面这句话可以完整的概括Specification的作用,但第一次理解或许会有些许困难,没关系,可以这么理解,Specification模式起作用 的,是每个Specification类,每一个Specification类,可以看成一张”规格书”,或者说是某种”规格约束”,而通过这张”规格 书”或者”规格约束”,我们能得到我们所想要的这种”规格”的对象,并且,不同的规格是可以组合起来,形成新的规格.如果还不明白.好吧,您知道乐高积木 吧?我们形象的把每个规格想象成一个不同的乐高模型,而不同的乐高模型组合在一起了,就形成了新的模型,以达到我们所需的结果. 如何实现Specification 了 解了什么是Specification,那接下去,您肯定会问,该怎么实现?其实很简单,Specification模式里面只有一个方法,我们有了”规 格书”,下一步,当然就是从不同的对象中得到符合”规格书”的对象,那这个匹配的过程就形成了一个动作抽象.IsSatisfiedBy就是帮助你从”对 象堆”中找到你所需”规格”的动作.如此.我们可以实现的Specification接口如下 public interface ISpecification<T> { bool IsSatisfiedBy(T candidate); } 但是,一般的Specification都提供了几个基本的组合操作,例如Add,Or,Not,可以利用它们分别组合成一个新的Specification.经过初步改动,最后ISpecification如下 public interface ISpecification<T> { bool IsSatisfiedBy(T candidate); ISpecification<T> Add(ISpecification<T> other); ISpecification<T> Or(ISpecification<T> other); ISpecification<T> Not(); } 为了重用可复用逻辑,我们定义了一个抽象类CompositeSpecification public abstract class CompositeSpecification<T> : ISpecification<T> { public abstract [...]

[转载].NET中的设计模式——一步步发现装饰模式 – 倪大虾 – 博客园. 前言 过去我的一个朋友常说，学习任何编程语言最困难的部分是运行“Hello World”，之后一切都很容易。多年以后，我才意识到他说的很对。学习设计模式的基本目标是要用它，尤其是帮助那些有扎实的OOP基础，而对设计模式很 困惑的人在设计中应用它。我不会为不同设计模式写很全面的参考，但我希望这些文章能让你入门。设计模式与特定的语言无关。虽然我用C#写了很多示例，但我 尽量避免一些C#特有的结构，因此它面向大部分人，尤其是使用C++的人。 装饰器模式允许我们动态为对象添加行为。下面我们先介绍一个场景，然后寻找替代方法。这会帮助我们认清该模式的真实用途，尤其在灵活性这方面。 思考过程 今天我们参考的不是一个实际的场景，有时可能会很奇怪，但它会帮助我们弄清这个模式及相关概念。我们的目标是添加将不同来源的信息存储到磁盘文件上的功能。所以，第一步我们定义一个接口，并实现它。IMessageWriter和IMessageReader接口分别用于写入和读取信息，他们的实现如下： view sourceprint? 01 interface IMessageWriter { 02 string Message { set; } 03 void WriteMessage(string filePath); 04 } 05 class MessageWriter : IMessageWriter { 06 private string message; 07 public string Message { set{message =value;} } 08 public virtual void WriteMessage(string filePath) [...]

[转载]JavaScript 设计模式 ：安全沙箱模式 – Stand Alone – 博客园. 沙箱模式常见于YUI3 core,它是一种采用同一构造器（Constructor）生成彼此独立且互不干扰（self-contained）的实例对象，而从避免污染全局对象的方法。 命名空间 JavaScript本身中没有提供命名空间机制，所以为了避免不同函数、对象以及变量名对全局空间的污染，通常的做法是为你的应用程序或者库创建一个唯一的全局对象，然后将所有方法与属性添加到这个对象上。 1 /* BEFORE: 5 globals */ 2  // constructors 3  function Parent() {} 4  function Child() {} 5  // a variable 6  var some_var = 1; 7  // some objects 8  var module1 = {}; 9 module1.data = {a: 1, b: 2}; 10 [...]

[转载]分层架构中的服务层-服务层的相关模式 – 软件设计开发 – 博客园. 1 引言 我们把服务层看做是暴露给用户界面的一个服务集合。大多数时候，我们会发现服务层的方法很容易满足用户的行为。在大多数企业应用中，CRUD是常用的操作。有的时候在一次操作中会处理多个实体。 服务层包括角色管理，数据验证，通知，调整返回给用户界面的数据，或者是整合系统可能的需求。 在谈到这些的时候，一些设计模式可能会有帮助。下面是一些在实现服务层的过程中有帮助的模式。 2 远程外观模式Remote Facade Pattern 远程外观模式是用来修改已经实现的方法的粒度的，外观模式没有实现任何新功能。它只是在原有的API之上包装一层不同的外观。为什么会需要外观模式呢？ 2.1 使用外观模式的动机 外观模式改变一个已经存在的对象的访问方式。举一个货运商在线服务的例子。每一个货运商对于注册运输的货物、跟踪货物和其他服务都有自己的 API，他们的细节在你的应用中可能都用不着。通过建立一个统一的API，你可以隐藏货运商API的细节，使得你的应用有一个清晰的接口。 换句话说，如果你想要你的接口处理一个简单的接口，这些必要性强迫你创建另外一个外观。实际上，这就是经典的远程外观模式的精确定义。 外观模式的好处就是允许你在一系列定义好的细粒度对象之上，定义粗粒度的接口。 面向对象使得你创建了很多小的对象，职责分离，细粒度对象。但是这些对象不适合分布式。为了是这些对象有效，你需要做出一些调整。你不想改变细 粒度对象的任何实现，但是你需要通过这些对象可以执行一批操作。在这种情况下，你需要创建新的方法，移动更大的数据。当你这么做的时候，实际上就是修改了 已经存在的接口粒度，也就是创建了外观模式。让我们回到货运订单的例子。通过你自己的API你可以发送多个订单，不用使用货运商的API来发送单个的订 单，这里我们假设货运商不支持多个订单的API。 2.2 远程外观模式和服务层 经过设计，服务层本质上拥有了粗粒度的接口，因为它更趋向于抽象一定数量的细小操作，来给客户端使用。在这点上，服务层已经是一种位于业务逻辑层和领域层对象之上的外观模式。