随笔分类 -  设计模式

摘要:前言建造者模式,将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。结构图Builder是为创建一个Product对象的各个部件指定的抽象接口。ConcreteBuilder是具体的建造者,实现Builder接口,构造和装配各个部件。可以有多个不同的具体的建造者。Product具体产品角色Director就是构建一个使用Builder接口的对象。代码实现首先来看一下产品类 public class Product { List parts = new List(); public void Add(string part) ... 阅读全文
posted @ 2013-10-11 23:12 aehyok 阅读(684) 评论(0) 推荐(0) 编辑
摘要:前言外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一系统更加容易使用.结构图SubSystem Class 子系统类集合 实现子系统的功能,处理Facade对象指派的任务,注意子类中没有Facade的任何信息,即没有对Facade对象的引用代码实现首先是四个子系统的类public class SubSystemOne { public void MethodOne() { Console.WriteLine("子系统方法一"); } } public class Sub... 阅读全文
posted @ 2013-09-12 00:31 aehyok 阅读(806) 评论(0) 推荐(0) 编辑
摘要:前言模版方法模式:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模版方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。结构图代码实现AbstractClass是抽象类,其实也就是一抽象类,定义并实现了一个模版方法,这个模版方法一般是一个具体方法,它给出了一个顶级逻辑的骨架,而逻辑的组成步骤在相应的抽象操作中,推迟到子类实现。顶级逻辑也有可能调用一些具体方法。 public abstract class AbstractClass { public abstract void PrimitiveOperation1(); publ... 阅读全文
posted @ 2013-09-10 23:19 aehyok 阅读(685) 评论(0) 推荐(0) 编辑
摘要:前言原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。结构图Prototype,原型类,声明一个克隆自身的接口ConcretePrototype1,ConcretePrototype2具体原型类,实现一个克隆自身的操作Client,调用,让一个原型克隆自身从而创建一个新的对象其实原型模式就是从一个对象再创建另外一个可定制的对象,而且不需知道任何创建的细节。代码实现Prototype原型类设计代码 public abstract class Prototype { public string ID { get; set; } pub... 阅读全文
posted @ 2013-06-01 08:40 aehyok 阅读(685) 评论(0) 推荐(0) 编辑
摘要:前言代理模式:为其他对象提供一种代理以控制对这个对象的访问。结构图Subject类,定义了RealSubject和Proxy的共用接口,这样就在任何使用RealSubject的地方都可以使用Proxy。RealSubject类,定义Proxy所代表的真实实体Proxy类,保存一个引用使得代理可以访问实体,并提供一个与Subject的接口相同的接口,这样代理就可以来替代实体。实例代码Subject类 public abstract class Subject { public abstract void Request(); }RealSubject类 pu... 阅读全文
posted @ 2013-05-31 08:27 aehyok 阅读(609) 评论(0) 推荐(0) 编辑
摘要:前言装饰模式:动态の给一个对象添加有些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。装饰模式结构图Component是定义一个对象接口,可以给这些对象动态添加职责ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责Decorator装饰抽象类,继承了Component,从外类来扩展Componnt类的功能,但对于Component来说,是无需知道Decorator的存在的代码实现Component类 public abstract class Component { public abstract void Operatio... 阅读全文
posted @ 2013-05-30 08:58 aehyok 阅读(622) 评论(0) 推荐(0) 编辑
摘要:前言策略模式:它定义了算法家族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化,不会影响到使用算法的客户。策略模式结构图Strategy:策略类,定义所有支持的算法的公共接口ConcreteStrategy1,ConcreteStrategy2,ConcreteStrategy3这三个是具体策略类,封装了具体的算法或行为,继承于StrategyContext上下文,用一个ConcreteStrategy来配置,维护一个对Strategy对象的引用。代码实现简单了解了一下,策略模式的定义和它的模式结构图之后,我们现在通过代码进行进一步的了解。Strategy类,定义所有支持的算法的公共 阅读全文
posted @ 2013-05-29 08:47 aehyok 阅读(820) 评论(2) 推荐(0) 编辑
摘要:单一职责原则单一职责原则,就一个类而言,应该仅有一个引起它变化的原因。 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,当变化发生时,设计会遭受到意想不到的破坏。事实上,我们完全可以找出来进行分类,分离。 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来,也不难,那就是如果你能够想到多余一个的动机去改变一个类,那么这个类就具有都与一个的职责,就应该考虑类的职责分离。开放-封闭原则开放-封闭原则,是说软件实体(类、模块、函数等等)应该可以扩展,但是不可修改。 ... 阅读全文
posted @ 2013-05-21 23:23 aehyok 阅读(2082) 评论(0) 推荐(0) 编辑
摘要:前言抽象工厂模式:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。抽象工厂模式最大的好处便是易于交换产品系列,由于具体工厂类,例如IFactory factory=new AccessFactory(),在一个应用中只需要在初始化的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置。我们的设计不能去防止需要的变更,那么我们的理想便是让改动变得最小,那么现在如果你要更改数据库访问,我们只需要更改具体工厂就可以做到。第二大好处是,它让具体的创建实例过程与客户端分离,客户端是通过他们的抽象接口操纵实例,产品的具体类名也被具体工厂的 阅读全文
posted @ 2013-05-20 13:56 aehyok 阅读(758) 评论(2) 推荐(1) 编辑
摘要:前言在第一回合中留下的问题,http://www.cnblogs.com/aehyok/archive/2013/05/19/3087497.html,现在就先处理一个简单的,只添加一个Department表。第二回合首先要建立部门类,假设只有两个字段部门ID,和部门名称。 public class Department { public int ID { get; set; } public string DeptName { get; set; } }下面看一下添加了部门表的UML类图IDpartment接口,用于客户端访问,解除与具体数据库访... 阅读全文
posted @ 2013-05-20 08:57 aehyok 阅读(727) 评论(0) 推荐(0) 编辑
摘要:前言首先关于抽象工厂模式的学习,我们需要慢慢的,由浅入深的进入。不能单刀直入,否则可能达不到预期学明白的目标。第一回合 首先我们从最简单的数据访问程序开始吧。下面先来看一个简单的小例子,代码很简单public class User{ public int ID{get;set;} public string Name{get;set;}}一个简单的实体类,也相当于在SqlServer数据库中建立了相同的数据表public class SqlServerUser{ public void Insert(User user) { Console.WriteL... 阅读全文
posted @ 2013-05-19 20:56 aehyok 阅读(785) 评论(0) 推荐(0) 编辑
摘要:前言工厂方法模式:定义一个用于创建对象的接口,让子类决定实例化那一个类。工厂方法使一个类的实例化延迟到其子类。简单工厂模式(http://www.cnblogs.com/aehyok/archive/2013/05/10/3072008.html)的最大优点在于工厂类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。工厂方法模式实现时,客户端需要决定实例化那一个工厂来实现运算类,选择判断的问题还是存在的,也就是说,工厂方法把简单工厂的内部逻辑判断移动到了客户端代码来进行。你想要加功能,本来是改工厂类的(简单工厂模式),而现在是修改客户端。工 阅读全文
posted @ 2013-05-13 21:46 aehyok 阅读(1166) 评论(8) 推荐(1) 编辑
摘要:前言 简单工厂模式根据提供的数据或者参数返回几个可能的类中的一个实例,说通俗点有点像面向对象编程中的多态性,一个基类,有多个派生类,在另外的调用程序中,根据参数来决定返回这个基类的哪个具体的派生类,返回值为基类类型,因为基类的引用可以指向派生类对象,而且这些所有的派生类都包含有基类的函数,也就是说派生类中有相同的函数,但是函数的实现可能不同。下面我只是来演示一下简单工厂模式,代码不会太复杂。所以大家可以使用Submile Text工具。使用方法博客文章链接http://www.cnblogs.com/aehyok/archive/2013/05/05/3059087.html可直接编译运行查. 阅读全文
posted @ 2013-05-10 22:18 aehyok 阅读(1377) 评论(1) 推荐(0) 编辑
摘要:前言单例模式(Singleton),保证一个类仅有一个实例,并提供一个访问它的全局访问点。通常我们可以让一个全局变量使得一个对象被访问,但它不能防止你实例化多个对象。一个最好的办法就是,让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建,并且它可以提供一个访问该实例的方法。单例模式 public class Singleton { private static Singleton instance; private static readonly object SyncRoot = new object(); ///程序... 阅读全文
posted @ 2013-05-08 20:43 aehyok 阅读(1933) 评论(7) 推荐(4) 编辑
摘要:本人菜菜一个,最近一直在博客园游走闲逛,看到了各种技术,各种各种……。便看到了大话设计模式这本书,下了电子版的看了看第一章,感觉相当不错,不仅通俗易懂,而且与实际案例相结合,可就是电子版的,鄙人很少看小说,所以立马在京东下单买了本。就是给力……看了看书,翻了翻,第一章简单工厂模式最后讲解的是UML类图,以前见到过,但从来没画过,也就是一眼而过。但是又好好看了看书,后面几乎每种模式都会用UML类图来阐述设计模式的整体架构。所以就回过头来好好把第一章最后的UML类图看了一下,在这里进行做一下笔记。首先看一张完整的UML类图图示样例第一(类):这个 "动物"矩形框,它就是一个类( 阅读全文
posted @ 2013-03-01 17:00 aehyok 阅读(1973) 评论(0) 推荐(5) 编辑

点击右上角即可分享
微信分享提示