zoukankan      html  css  js  c++  java
  • 设计模式

    随笔分类 - 设计模式

    大话设计模式阅读笔记
    摘要: 设计模式的实现并不难,对着例子来,很快就能敲出来。但是,在什么情况下用什么设计模式,这是个问题,最近总结了一下:设计模式用法单例保证类的实例只有一个简单工厂根据参数创建对应具体子类策略算法、规则的封装、传入具体调用,调用具体算法装饰者动态对一个对象进行增属性、调用方法等操作,链式操作,随意组合。...阅读全文
    posted @ 2013-11-29 15:01 逆心 阅读(324) | 评论 (0) 编辑
    摘要: 在NHibernate中,ISessionFactory是线程安全的,对应一个数据库。它是生成ISession的工厂。而ISession是线程不安全的。 创建一个ISessionFactory需要消耗比较多的资源。因此,我们只在程序初始化的时候创建一次,以后就一直使用这个ISessionFactory。 而ISession的创建只消耗很少的资源。因此我们可以随意创建。一、原始单例模式封装的ISessionFactory 因此,对于ISessionFactory,我们使用饿汉单例模式实现它。 原始饿汉单例模式封装ISessionFactory实例: //密封类 ...阅读全文
    posted @ 2013-10-10 12:40 逆心 阅读(305) | 评论 (0) 编辑
    摘要: 访问者模式(Visitor),表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 下面给出访问者模式的结构图: 从类图可以看出,访问者模式那是相当复杂啊! 下面给出访问者模式的基本代码结构:namespace ConsoleApplication1{ //Visitor类,为该对象结构中ConcreteElement的每一个类声明一个Visit操作。 abstract class Visitor { public abstract void VisitConcreteElementA(Co...阅读全文
    posted @ 2013-03-24 02:56 逆心 阅读(104) | 评论 (0) 编辑
    摘要: 解释器模式(interpreter),给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。 解释器模式需要解决的是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言的句子。这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题。 下面给出解释器模式的结构图: 下面给出解释器模式的基本代码结构:namespace ConsoleApplication1{ //AbstractExpresstion(抽象表达式),声明一个抽象的解释操作,这个接口为抽象语法树中所有的节点所共享 ...阅读全文
    posted @ 2013-03-24 02:01 逆心 阅读(120) | 评论 (0) 编辑
    摘要: 享元模式(Flyweight),运用共享技术有效地支持大量细粒度的对象。 下面给出享元模式的结构图: 下面给出享元模式的基本代码结构:namespace ConsoleApplication1{ //Flyweight类,它是所有具体享元类的超类或接口,通过这个接口,Flyweight可以接受并作用于外部状态 abstract class Flyweight { public abstract void Operation(int extrinsicstate); } //ConcreteFlyweight是继承Flyweight...阅读全文
    posted @ 2013-03-24 00:13 逆心 阅读(55) | 评论 (0) 编辑
    摘要: 中介者模式(Mediator),用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变他们之间的交互。 来看中介者模式的结构图: Colleague叫做抽象同事类,而ConcreteColleague是具体同事类,每个具体同事只知道自己的行为,而不了解其他同时类的情况,但它们却都认识中介者对象,Mediator是抽象中介者,定义了同事对象到中介者对象的接口,ConcreteMediator是具体中介者对象,实现抽象类方法,它需要知道所有具体同事类,并从具体同事接收信息,向具体同事对象发出命令。 下面给出中介者模式的基本代...阅读全文
    posted @ 2013-03-23 23:15 逆心 阅读(46) | 评论 (0) 编辑
    摘要: 职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它位置。 下面给出职责链模式的结构图: 下面给出职责链模式的基本代码结构:namespace ConsoleApplication1{ //Handler类,定义一个处理请示的接口 abstract class Handler { protected Handler successor; public void SetSuccesso...阅读全文
    posted @ 2013-03-23 21:49 逆心 阅读(53) | 评论 (0) 编辑
    摘要: 命令模式(Command),将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销操作。 下面给出命令模式的结构图: 下面是命令模式的基本结构代码:namespace ConsoleApplication1{ abstract class Command { protected Receiver receiver; public Command(Receiver receiver) { this.receiver = receiver; ...阅读全文
    posted @ 2013-03-20 01:37 逆心 阅读(90) | 评论 (0) 编辑
    摘要: 合成/聚合复用原则(CARP),尽量使用合成/聚合,尽量不要使用类继承。 合成和聚合都是关联的特殊种类。聚合表示一种弱的“拥有关系”,体现的是A对象可以包含B对象,但B对象不一定是A对象的一部分;合成则是一种枪的‘拥有’关系,体现了严格的部分和整体的关系,部分和整体的声明周期一样。比方说,大雁有两个翅膀,翅膀与大雁是部分和整体的关系,并且它们的声明周期是相同的,于是大雁和翅膀就是合成关系。而大雁是群居动物,所以每只大雁都是属于一个雁群,一个雁群可以有多只大雁,所以大雁和雁群是聚合关系。 合成/聚合复用原则的好处是,有限使用对象的合成/聚合将有助于你保持每个类被封装,并被集中在单个任务上...阅读全文
    posted @ 2013-03-20 00:00 逆心 阅读(71) | 评论 (0) 编辑
    摘要: 迭代器模式(Iterator),提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露该对象的内部表示。 当你需要访问一个聚集对象,而且不管这些对象是什么都需要遍历的时候,你就应该考虑用迭代器模式。同时,你需要对聚集有多重方式遍历时们可以考虑用迭代器模式。 实际上,到目前为止,迭代器的实用价值不大,因为很多高级编程语言,如C#,java等本身已经把这个模式做在语言中了,就是 foreach。另外想IEnumerable接口也是为迭代器模式准备的。 下面给出迭代器模式的UML示例图: 下面给出迭代器模式的代码结构:namespace ConsoleApplication1{ ...阅读全文
    posted @ 2013-03-19 23:17 逆心 阅读(76) | 评论 (0) 编辑
    摘要: 组合模式(Composite),将对象组合成属性结构以表示'部分-整体'的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性。 下面给出组合模式的UML图: 来看组合模式的基本代码结构:namespace ConsoleApplication1{ //Component为组合中的对象声明接口 abstract class Component { protected string name; public Component(string name) { this.name = name...阅读全文
    posted @ 2013-03-19 22:15 逆心 阅读(546) | 评论 (0) 编辑
    摘要: 备忘录模式(Memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。 以下给出备忘录模式的UML图: Originator(发起人):负责创建一个备忘录Memento,用以记录当前时刻它的内部状态,并可使用备忘录恢复内部状态。Originator可根据需要决定Memento存储Originator的哪些内部状态。 Memento(备忘录):负责存储Originnator对象的内部状态,并可防止Originator以外的其他对象访问备忘录Memento,备忘录有两个接口,Caretaker只能看到备...阅读全文
    posted @ 2013-03-19 20:11 逆心 阅读(287) | 评论 (0) 编辑
    摘要: 适配器模式(Adapter),将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 在软件开发中,系统的数据行为都正确,但接口不符,我们应该考虑用适配器,目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况。 下面给出适配器模式的UML图: 下面来看下适配器模式的代码结构图:namespace ConsoleApplication1{ //Target类,客户所期望的接口 class Target { ...阅读全文
    posted @ 2013-03-19 19:51 逆心 阅读(60) | 评论 (0) 编辑
    摘要: 状态模式(State),当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况,把状态的判断逻辑转到到表示不同状态的一系列类当中,可以把复杂的逻辑判断简化。当然,如果这个状态的判断很简单,就没有必要使用状态模式了。 如果我没理解错的话,说白了就是如果判断很长,就把判断分割到多个类里面。 状态模式的好处是将与特定状态相关的行为局部化,并且将不同状态的行为分隔开来。状态模式通过吧各种状态转移逻辑分布到State子类之间,来减少相互间的依赖。 问:什么时候考虑使用状态模式呢? 答:当一个对象的行为...阅读全文
    posted @ 2013-03-19 01:53 逆心 阅读(688) | 评论 (0) 编辑
    摘要: 抽象工厂模式(Abstract Factory),提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。 以下给出抽象工厂方法模式的UML图: 回到《大话设计模式》里面的双数据库访问的例子:namespace ConsoleApplication1{ class User { private int _id; public int ID { get { return _id; } set { _id = value; } } private...阅读全文
    posted @ 2013-03-19 00:43 逆心 阅读(99) | 评论 (0) 编辑
    摘要: 观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使观察者对象它们能够自动更新自己。 说白了就是说一个对象,能够通过另外一个对象(通知者)的状态改变自身的状态。 问:什么时候应该用观察者模式呢? 答:当一个对象的改变需要同时改变其他对象的时候。 观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象,而不是依赖具体。从而使得各自的变化都不会影响另一边的变化。 下面给一个观察者模式的UML图: 下面给出观察者模式的代码结构:namespace ConsoleApplication...阅读全文
    posted @ 2013-03-18 22:45 逆心 阅读(109) | 评论 (0) 编辑
    摘要: 建造者模式(Builder),将一个复制对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。 建造者模式的UML图: Builder是为创建一个Product对象的各个部件指定的抽象接口。 ConcreteBuilder是具体的建造者,实现Builder接口,构造和装备各个部件。 Product是产品角色,也就是具体的产品。 Director是指挥者,它是构建一个使用Builder接口的对象。 以下给出建造者模式的基本代码结构:namespace ConsoleApplication1{ //Product类 class Pr...阅读全文
    posted @ 2013-03-18 00:01 逆心 阅读(58) | 评论 (0) 编辑
    摘要: 外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 怎么叫更加容易使用呢?多个方法变成一个方法,在外观看来,只需知道这个功能完成哪些功能就OK了,不必记得一大堆对象,一大堆方法。 外观模式UML图: 外观模式的基本结构代码:namespace ConsoleApplication1{ //四个子系统类 class SubSystemOne { public void MethodOne() { Console.WriteLine("...阅读全文
    posted @ 2013-03-17 23:04 逆心 阅读(82) | 评论 (0) 编辑
    摘要: 模板方法模式,定义一个操作中的算法的骨架,而将一些步骤移动(变动的部分)到子类中,模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 模板方法的关键点在于对重复代码的提炼(要精准)。模板方法就是提供了一个很好的代码复用平台。 以下给出模板方法模式的UML图: 以下给出模板方法模式的代码结构:namespace ConsoleApplication1{ abstract class AbstractClass { public abstract void PrimitiveOperation1(); public...阅读全文
    posted @ 2013-03-17 22:22 逆心 阅读(62) | 评论 (0) 编辑
    摘要: 原型模式(Prototype),用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 简单说来原型模式就是从一个对象再创建另外一个可定制的对象,而且不需知道任何创建的细节。 原型模式UML图: 原型模式的基本代码结构:namespace ConsoleApplication1{ abstract class Prototype { private string id; public Prototype(string id) { this.id = id; } p...阅读全文
    posted @ 2013-03-17 21:41 逆心 阅读(145) | 评论 (0) 编辑
    摘要: 工厂方法模式(Factory Method),定义了一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。 工厂方法模式在实现时,客户端需要决定实例化哪一个工厂来实现运算类,选择判断的问题还存在,也就是说,工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。想要加功能,本来是修改工厂类的,而现在是修改客户端。 下面给出工厂方法模式UML图: 工厂方法模式示例:namespace 工厂方法模式{ //数据库类 class DataBase { public virtual string SelectTopOne...阅读全文
    posted @ 2013-03-16 23:39 逆心 阅读(108) | 评论 (0) 编辑
    摘要: 代理模式(Proxy),为其他对象提供一种代理以控制对这个对象的访问。 在某些情况下,一个对象不适合或者不能直接引用另一个对象,而代理对象可以在客户端和目标对象之间起到中介的作用。 代理模式的优点: (1)、职责清晰,真实的角色就是实现实际的业务逻辑,不用关心其他非本职责的事务,通过后期的代理完成一件完成事务,附带的结果就是编程简洁清晰。 (2)、代理对象可以在客户端和目标对象之间起到中介的作用,这样起到了的作用和保护了目标对象的作用。 (3)、高扩展性 代理模式的UML图: 代码示例:namespace ConsoleApplication1{ abs...阅读全文
    posted @ 2013-03-16 22:37 逆心 阅读(83) | 评论 (0) 编辑
    摘要: 装饰模式(Decorator),动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。 装饰者模式隐含的是通过一条条装饰链去实现具体对象,每一条装饰链都始于一个Componet对象,每个装饰者对象后面紧跟着另一个装饰者对象,而对象链终于ConcreteComponet对象。 用粗略的话讲:装饰模式就是为已有功能动态地添加更多功能的一种方式。 何为动态。比如打折策略。3折后再减30元再打8折, UML图如下: Component是定义一个对象接口,可以给这些对象动态地添加职责。ConcreteComponent是定义了一个具体的对象,也可以给这个对...阅读全文
    posted @ 2013-03-16 16:43 逆心 阅读(80) | 评论 (0) 编辑
    摘要: 策略模式(Strategy):它定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户。 策略模式是一种定义一系列算法的方法,从概念上来看,所有这些算法完成的都是相同的工作,只是实现不同,它可以以相同的方式调用所有的算法,减少了各种算法类与使用算法类之间的耦合。事实上你可以将一个继承自抽象策略类的称为具体策略,就是策略模式中的策略1,策略2...... 策略模式的优点: 策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法的公共功能。策略模式的另一个优点是简化了单元测试,因为每个算法都有...阅读全文
    posted @ 2013-03-15 22:44 逆心 阅读(116) | 评论 (0) 编辑
    摘要: 简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现。 使用场景:工厂类负责创建的对象比较少;客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。 优点: 工厂类是整个模式的关键。包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象。 通过简单工厂类,对外部来说,仅仅需要知道传入什么参数就能返回何种对象就可以了。不必再理会到对象是怎样生成的,逻辑是如何实现等等。 缺点: 由于工厂类集中了...阅读全文
    posted @ 2013-03-15 14:25 逆心 阅读(141) | 评论 (0) 编辑
    摘要: 单例模式(Singleton):保证一个类仅有一个实例,并提供一个访问它的全局访问点。一、单例模式 通常我们可以让一个全局变量使得一个对象被访问,但它不能防止你实例化多个对象。一个最好的办法就是,让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建,并且它可以提供一个访问该实例的方法。 单例模式结构图: Singleton类,定义一个GetInstance操作,允许客户访问它的唯一实例。GetInstance是一个静态方法,主要负责创建自己的唯一实例。 单例模式示例:namespace ConsoleApplication1{ public class Si...阅读全文
  • 相关阅读:
    【Ubuntu 笔记】翻译 32.1 Job Control
    【Class 学习笔记】 浮点数的储存,运算
    【Ubuntu学习笔记】 安装篇-锐捷、scim、root改密码
    【Ubuntu学习笔记】安装篇-网络配置遇到的问题
    MySQL增删改查
    Spring MVC详解
    SSH和SSM对比总结
    hibernate工作原理
    JavaBean与xml互转的方法详解
    spring MVC如何获取session传值到前台
  • 原文地址:https://www.cnblogs.com/zxtceq/p/5212539.html
Copyright © 2011-2022 走看看