设计模式学习记录

  1. 简单工厂模式:
    • 创建型模式
    • 基本实现:所有产品类继承自产品接口/父类,工厂类根据输入创建产品实例
    • 全部的创建逻辑都在工厂类中实现,客户端只需要了解创建参数,而无需关心创建实例的具体细节
简单工厂模式
//父类
public abstract class Operation
{
    public int num1;
    public int num2;
    public abstract int GetResult();
}

//产品类1
public class AddOperation : Operation
{
    public override int GetResult()
    {
        return num1 + num2;
    }
}

//产品类2
public class MinusOperation : Operation
{
    public override int GetResult()
    {
        return num1 - num2;
    }
}

//产品工厂
public class OperationFatory
{
    public static Operation CreatOperation(string op)
    {
        Operation operation = null;
        if (op == "+")
        {
            operation = new AddOperation();
        }
        else if (op == "-")
        {
            operation = new MinusOperation();
        }

        return operation;
    }
}

//客户端调用
Operation operation=OperationFatory.CreatOperation("+");
  1. 策略模式
    • 定义了算法家族,分别封装起来,让彼此之间可以相互替换
    • 基本实现:所有的具体算法都继承自算法父类/接口,在上下文中包含了对算法类的引用
    • 与工厂方法的区别:工厂方法是创建了具体的产品,策略模式是通过在创建上下文对象实现对不同算法的引用。工厂方法侧重于创建,策略模式侧重于对某一具体方法的引用
策略模式
//算法父类
public abstract class Strategy
{
    public abstract void AlgorithmInterface();
}

//A类算法
public class ConcrateStrategyA : Strategy
{
    public override void AlgorithmInterface()
    {
        //A类算法实现
    }
}

//B类算法
public class ConcrateStrategyB : Strategy
{
    public override void AlgorithmInterface()
    {
        //B类算法实现
    }
}

 //C类算法
public class ConcrateStrategyC : Strategy
{
    public override void AlgorithmInterface()
    {
        //C类算法实现
    }
}

//上下文类
public class Context
{
    Strategy strategy;

    public Context(Strategy strategy)
    {
        this.strategy = strategy;
    }

    public void ContextInterface()
    {
        this.strategy.AlgorithmInterface();
    }
}

//客户端调用
Context context=new Context(new ConcrateStrategyA ());
context.ContextInterface();
  1. 装饰模式
    • 解释:动态的给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更灵活
    • 即通过创建装饰者类来包裹另一对象并同时添加自身特有的功能
    • ConcrateComponent根据实际情况添加或删除


      装饰模式
public abstract class Component
{
    public abstract void Operation();
}

public abstract class Decorator : Component
{
    protected Component component;

    public void SetComponent(Component c)
    {
        component = c;
    }

    public override void Operation()
    {
        if (component != null)
        {
            component.Operation();
        }
    }
}

public class ConcrateDecoratorA : Decorator
{
    public void AOperation()
    {
        //A特有的功能
    }

    public override void Operation()
    {
        base.Operation();
        AOperation();
    }
}

public class ConcrateDecoratorB : Decorator
{
    public void BOperation()
    {
        //B特有的功能
    }

    public override void Operation()
    {
        base.Operation();
        BOperation();
    }
}

//客户端调用
        ConcrateDecoratorA ca = new ConcrateDecoratorA();
        ConcrateDecoratorB cb = new ConcrateDecoratorB();
        //ConcrateDecoratorC cc = new ConcrateDecoratorC();
        cb.SetComponent(ca);
        //cc.SetComponent(cb);
        cb.Operation();
        //cc.Operation();  //最终产生链式关系
  1. 代理模式
    • 解释:为其他对象提供一个代理以控制对这个对象的访问
    • 代理类和真实请求类同继承于请求接口(或抽象类),代理类包裹真实请求类
    • 该模式一般用于远程代理、虚拟代理、安全代理


      代理模式
public abstract class Subject
{
    public abstract void Request();
}

public class RealSubject : Subject
{
    public override void Request()
    {
        //真实请求
    }
}

public class Proxy : Subject
{
    RealSubject realSubject;
    public override void Request()
    {
        if (realSubject == null)
        {
            realSubject = new RealSubject();
        }
        realSubject.Request();
    }
}
  1. 工厂方法模式

  2. 原型模式:解决结构复杂的对象的创建工作

public object Clone()
{
  return this.MemberwiseClone();
}
  1. 模板方法模式:在父类中定义抽象方法以及算法骨架,通过在不同的子类中重写抽象方法,借助多态实现不同的行为(即:将父类中可变的行为延迟到子类中实现)
  2. 外观模式:有多个类,每个类有自己的行为,在外观类中实例化这些类,并定义方法对这些类的行为进行组合。调用者只需要调用外观类中的方法即可
  3. 建造者模式:主要用于构建复杂的对象,这些对象内部构建间的建造顺序通常时未定的,但对象内部的构建通常面临着复杂的变化

在抽象父类中定义对象的构建顺序,在不同的子类中实现不同的构建方法。通过在指挥者类中使用里氏替换法则声明父类对象实现不同的构建

  1. 抽象工厂模式:数据库案例

  2. 状态模式:

    • 消除庞大的分支语句
    • 当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,可以使用状态模式
  3. 适配器模式:

    • 主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致
    • 适配器模式分为:类适配器模式,对象适配器模式


      类适配器模式

      对象适配器
  4. 备忘录模式:

    • 应用:保存信息并还原
    • 使用Caretaker保存备忘录并用于还原


      备忘录模式

14 组合模式:
- 即创建xml文档的方式,所有的元素都可以看作xmlNode,通过对xmlNode组合获得xml文档
- 当需求中体现的是部分与整体层次结构时可以使用组合模式


组合模式
  1. 单例模式

  2. 桥接模式

    • 将抽象部分与它的实现部分分离,使它们都可以独立地变化
      桥接模式
abstract class Abstractor
{
    protected Implementor implementor;

    public void SetImplementor(Implementor implementor)
    {
        this.implementor = implementor;
    }

    public virtual void Operation()
    {
        implementor.Operation();
    }
}

abstract class Implementor
{
    public abstract void Operation();
}
  1. 命令模式
    • 将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
    • Receiver可以是任意类,只要它知道如何真正执行一个命令


      命令模式
public abstract class Command
{
    public Receiver receiver;

    public Command(Receiver rcv)
    {
        receiver = rcv;
    }

    public abstract void Excute();
}

public class ConcrateCommand : Command
{
    public ConcrateCommand(Receiver rcv) : base(rcv)
    { }

    public override void Excute()
    {
        receiver.Action();
    }
}

public class Invoker
{
    public List<Command> commands;

    public void AddCommand(Command cmd)
    { }

    public void RemoveCommand(Command cmd)
    { }

    public void Notify()
    {
        for (int i = 0; i < commands.Count; i++)
        {
            commands[i].Excute();
        }
    }
}

public class Receiver
{
    public void Action()
    {
        //真正执行命令
    }
}
  1. 职责链模式
    • 当用户提交一个请求时,请求按职责链传递直至有一个ConcrateHandler处理
    • 可方便添加、修改处理者


      职责链模式
public abstract class Manager
{
    public Manager nextHandler;
    public void SetNextHandler(Manager nth)
    {
        nextHandler = nth;
    }

    public abstract void Handle(Request res);
}

public class JingLi : Manager
{
    public override void Handle(Request res)
    {
        if (res.num<2)
        {
            Debug.Log("经理处理");
        }
        else
        {
            nextHandler.Handle(res);
        }
    }
}

public class ZongJian : Manager
{
    public override void Handle(Request res)
    {
        if (res.num < 5)
        {
            Debug.Log("总监处理");
        }
        else
        {
            nextHandler.Handle(res);
        }
    }
}

public class ZongJingLi : Manager
{
    public override void Handle(Request res)
    {
        Debug.Log("总经理处理," + res.num);
    }
}

public class Request
{
    public int num;
}
  1. 中介者模式
    • 多个同事类通过中介者交互,即中介者了解所有的同事类
    • 同事类不需要了解其他同事类,只需要了解中介者类,处理逻辑在中介者类中实现


      中介者模式
public abstract class Mediator
{
    public Colleague colleagueA;
    public Colleague colleagueB;

    public abstract void TransformMessage(Colleague colleague, string str);
}

public abstract class Colleague
{
    public Mediator mediator;

    public Colleague(Mediator mediator)
    {
        this.mediator = mediator;
    }

    public abstract void SendMessage(string str);
    public abstract void GetMessage(string str);
}

public class ConcrateMediator : Mediator
{
    public override void TransformMessage(Colleague colleague, string str)
    {
        if (colleague == colleagueA)
        {
            colleagueB.GetMessage(str);
        }
        else if (colleague == colleagueB)
        {
            colleagueA.GetMessage(str);
        }
    }
}

public class ConcrateColleagueA : Colleague
{
    public ConcrateColleagueA(Mediator mediator) : base(mediator)
    { }

    public override void GetMessage(string str)
    {
        Debug.Log("A获得信息:" + str);
    }

    public override void SendMessage(string str)
    {
        mediator.TransformMessage(this,str);
    }
}

public class ConcrateColleagueB : Colleague
{
    public ConcrateColleagueB(Mediator mediator) : base(mediator)
    { }

    public override void GetMessage(string str)
    {
        Debug.Log("B获得信息:" + str);
    }

    public override void SendMessage(string str)
    {
        mediator.TransformMessage(this, str);
    }
}
  1. 享元模式
  2. 解释器模式
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容