.NET设计模式系列
文章平均质量分 78
kalen_chen
这个作者很懒,什么都没留下…
展开
-
(创建型模式)Singleton 单件模式
概述Singleton模式要求一个类有且仅有一个实例,并且提供一个全局的访问点。这就提出了一个问题:如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例?客户程序在调用某一个类时,它是不会考虑这个类是否只能有一个实例等问题的,所以,这应该是类设计者的责任,而不是类使用者的责任。从另一个角度来说,Singleton模式其实也是一种职责模式。因为我们创建了一个对象,这个对象扮演了独一无二转载 2007-04-29 14:54:00 · 789 阅读 · 0 评论 -
(结构型模式)Bridge 桥接模式
概述在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度”的变化?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就是要使用Bridge模式。 意图将抽象部分与实现部分分离,使它们都可以独立的变化。 结构图图1Bridge模式结构图 生活中的例子桥接模式将抽象部分与它的转载 2007-05-21 16:28:00 · 827 阅读 · 0 评论 -
(结构型模式)Adapter 适配器模式
概述在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?这就是本文要说的Adapter模式。意图将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原来由于接口不兼容而不能一起工作的那些类可以转载 2007-05-17 19:54:00 · 757 阅读 · 0 评论 -
《解剖PetShop》系列之一
前言:PetShop是一个范例,微软用它来展示.NET企业系统开发的能力。业界有许多.NET与J2EE之争,许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩,对于我们开发人员而言,没有必要过多关注。然而PetShop随着版本的不断更新,至现在基于.NET 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,有很多可以借鉴之处。PetS转载 2007-05-15 16:07:00 · 713 阅读 · 0 评论 -
《解剖PetShop》系列之二
二.PetShop数据访问层之数据库访问设计系列一从整体上分析了PetShop的架构设计,并提及了分层的概念。从本部分开始,将依次对各层进行代码级的分析,以求获得更加细致而深入的理解。在PetShop 4.0中,由于引入了ASP.NET 2.0的一些新特色,所以数据层的内容也更加的广泛和复杂,包括:数据库访问、Messaging、MemberShip、Profile四部分。在系列二中,将介绍有转载 2007-05-16 11:35:00 · 699 阅读 · 0 评论 -
《解剖PetShop》系列之三
三.PetShop数据访问层之消息处理在进行系统设计时,除了对安全、事务等问题给与足够的重视外,性能也是一个不可避免的问题所在,尤其是一个B/S结构的软件系统,必须充分地考虑访问量、数据流量、服务器负荷等问题。解决性能的瓶颈,除了对硬件系统进行升级外,软件设计的合理性尤为重要。在前面曾提到,分层式结构设计可能会在一定程度上影响数据访问的性能,然而与它给设计人员带来的好处相比,几乎可以忽略。转载 2007-05-16 18:01:00 · 1166 阅读 · 0 评论 -
创建型模式总结
概述创建型模式,就是用来创建对象的模式,抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。本文对五种常用创建型模式进行了比较,通过一个游戏开发场景的例子来说该如何使用创建型模式。 为什么需要创建型模式所有的创建型模式都有两个永恒的主旋律:第一, 它们都将系统使用哪些具体类的信息封装起来。第二, 它们隐藏了这些类的实例是如何被创建和组织的。转载 2007-05-12 11:08:00 · 664 阅读 · 0 评论 -
(创建型模式)Prototype 原型模式
概述在软件系统中,有时候面临的产品类是动态变化的,而且这个产品类具有一定的等级结构。这时如果用工厂模式,则与产品等级结构平行的工厂方法类也要随着这种变化而变化,显然不大适合。那么如何封装这种动态的变化?从而是依赖于这些易变对象的客户程序不随着产品类变化? 意图用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 结构Prototype模式结构图生活中转载 2007-05-10 15:13:00 · 646 阅读 · 0 评论 -
(创建型模式)Factory Method工厂方法模式
概述在软件系统中,经常面临着“某个对象”的创建工作,由于需求的变化,这个对象的具体实现经常面临着剧烈的变化,但是它却拥有比较稳定的接口。如何应对这种变化?提供一种封装机制来隔离出“这个易变对象”的变化,从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变? 意图定义一个用户创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类转载 2007-05-09 21:25:00 · 667 阅读 · 0 评论 -
(创建型模式)Builder 建造者模式
概述在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法确相对稳定。如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保持系统中的“稳定构建算法”不随着需求改变而改变?这就是要说的建造者模式。 意图将一个复杂的构建与转载 2007-05-08 18:01:00 · 658 阅读 · 0 评论 -
(创建型模式)Abstract Factory 抽象工厂模式
概述在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时由于需求的变化,往往存在着更多系列对象的创建工作。如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式。 意图提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。转载 2007-05-07 20:59:00 · 1135 阅读 · 1 评论 -
(结构型模式)Decorator 装饰模式
概述在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入了静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响降为最低?这就是本文要讲的Decorator模转载 2007-05-22 15:45:00 · 712 阅读 · 0 评论