web前端 38

工厂模式,用自己的话概括设计模式

By admin in web前端 on 2019年5月6日

web前端 1

1)特点 2)使用场景及补充

本文源自深入浅出设计模式. 只不过我是使用C#/.NET Core实现的例子.

Javascript设计模式-工厂模式

工厂模式(Factory):

 

我理解工厂模式,就是把相关的多个类提供一个统一入口的一个模式,让你从一个入口就可以获得多个类,提高工作效率.

但是对于工厂模式也会有三种类型的实现方式,分别是:简单工厂模式,工厂方法模式和抽象工厂模式.它们分别是在各自基础上有一定的改进.

1)将对象的创建实现隔离

前言

当你看见new这个关键字的时候, 就应该想到它是具体的实现.

web前端 2

这就是一个具体的类, 为了更灵活, 我们应该使用的是接口(interface).

有时候, 你可能会写出这样的代码:

web前端 3

这里有多个具体的类被实例化了, 是根据不同情况在运行时被实例化的. 

当你看到这样的代码, 你就会知道当有需求需要对其进行修改或者扩展的时候,
你就得把这个文件打开, 然后看看在这里应该添加或者删除点什么.
这类的代码经常会分散在程序的多个地方,
这维护和更新起来就很麻烦而且容易出错.

针对interface进行编程的时候,
你知道可以把自己独立于系统未来可能要发生的变化. 为什么呢?
因为如果你针对interface编程,
那么对于任何实现了该接口的具体类对你来说都可以用, 多态吗.

简单工厂模式

也被叫做静态工厂模式(Simple Factory Patter),主要用于创建同一类的对象.

适用情况:如果被要求写一些球类的实现,那么一般情况的话我们会这样实现:

var Football = function(){
    this.name = "football";
    ....
}
var Basketball = function(){
    this.name = "basketball";
    ....
}

这种写法有一些缺陷:返回了多个类,不便于他人使用.因此我们考虑把这些类似的类封装到一个工厂里面,也就有了我们的简单工厂模式:

var BallFactory;
!(function(){
    BallFactory = function(type,cfg){
        var Football = function(cfg){
            this.name = 'football';
            console.log(this.name + " in the prototype");
        };
        Football.prototype = {
            call:function(){console.log(this.name)},
            sell:function(){}
        };
        var Basketball = function(cfg) {
            this.name = "basketball";
            console.log(this.name);
        };

        var cfg = cfg ||{};
        switch(type){
            case 'football':
                return new Football(cfg);
                break;
            case 'basketball':
                return new Basketball(cfg);
                break;
        }
    };
})();

var aFootball = BallFactory('football');
aFootball.call();

因此使用BallFactory把这些内容包裹起来给其他人使用就会避免返回了多个类的问题,所以这就是简单工厂模式想解决的问题:
统一创建的入口.

当然在实际的使用过程中,我们会使用一些其它技巧:

如果工厂的产品中有很多重复部分,那么我们需要把重复的部分抽象出来成为共同的部分,不同的部分放入switch里面:

var GetChildren = function(cfg){
    cfg = cfg||{};
    this.name = cfg.name;
    this.height = cfg.height;
    this.speak = function(){};

    //抽离出不同的部分
    switch(cfg.gender){
        case "boy":
            this.gender = cfg.gender;
            this.moustouch = ....
            .....; //特有部分
            break; 
        case "girl":
            this.gender = cfg.gender;
            .......
            break;
    }
    return this;
}
var aBoy = GetChildren({.....}); 

2)适用于有继承结构的对象创建,根据参数决定实例化的内容

项目原始需求

有一个前沿的披萨店, 做披萨, 下面是订购披萨的类:

web前端 4

new一个披萨, 然后按照工序进行加工 最后返回披萨.

但是, 一个披萨店不可能只有一种披萨, 可能会有很多中披萨,
所以你可能会这样修改代码:

web前端 5

根据传入的类型, 创建不同的披萨, 然后加工返回.

然后问题来了, 随着时间的推移,
一个披萨店会淘汰不畅销的披萨并添加新品种披萨.

使用上面的代码就会出现这个问题, 针对需求变化,
我不得不把OrderPizza的部分代码改来改去:

web前端 6

从这里, 我们也可以看到, 上半部分是会变化的部分, 下半部分是不变的部分,
所以它们应该分开(把变化的部分和不变的部分分开, 然后进行封装).

结构应该是这样的:

web前端 7

右上角是变化的部分, 把这部分封装到一个对象里, 它就是用来创建披萨的对象,
我们把这个对象叫做: 工厂.

工厂负责创建对象的细节工作. 我们创建的这个工厂叫做SimplePizzaFactory,
而orderPizza()这个方法就是该工厂的一个客户(client).

任何时候客户需要披萨的时候, 披萨工厂就会给客户创建一个披萨.

web前端,接下来, 我们就建立这个简易的披萨工厂:

web前端 8

就是通过传入的类型参数, 建立并返回不同类型的披萨.

这样我们就把披萨创建的工作封装到了一个类里面, 发生变化的时候,
只需要修改这一个类即可.

注意: 有时候上面这种简单工厂可以使用静态方法, 但是这样也有缺点,
就是无法通过继承来扩展这个工厂了.

回来修改PizzaStore这个类:

web前端 9

工厂是从构造函数传入的, 并在PizzaStore里面保留一个引用.

在OrderPizza()方法里面, 我们使用工厂的创建方法代替了new关键字,
所以在这里没有具体的实例化.

工厂方法模式

在简单工厂模式的基础上,我们已经解决了入口不统一的问题,但是还有一个问题没有解决:

加入一个新的类需要修改多部分:首先我们需要在BallFactory工厂内部加入如何实现,然后加到switch部分;所以这是一次修改的需求,我们需要修改多个地方.

那么我们看能不能尝试更抽象一点,尽可能减少需要修改的地方;

var BallFactory = function(type,cfg){
    this.name = cfg.name; //共同的部分放在这里
    return this[type](cfg);
};

BallFactory.prototype = {
    football:function(cfg){
        console.log("这里加入和football相关的独特内容" +this.name);
    },
    basketball:function(cfg) {
        console.log("这里加入和basketball相关的独特内容" +this.name);
    }
};
var aBall = new BallFactory("football",{name:"football"}); //football in the prototype

所以这里加入了一个return this[type](cfg)的方法自动代替了之前的switch的方法.以后需要加入内容只需要修改BallFactory的prototype就可以了.

当然我们还可以添加一种安全模式来解决如果不在构造函数前面加上new的话,会报错的问题.解决的思路其实是把new封装在构造函数之内:

var BallFactory = function(type,cfg){
    if(!(this instanceof BallFactory)){
        return new BallFactory(type,cfg); //多一行判断即:如果没有带new,我自己帮你new一个返回就好;
    }
    this.name = cfg.name;
    return this[type](cfg);
};

var aBall = BallFactory("football",{name:"football"}); //这里如果掉了new也会正常执行;

所以,我们可以看到的是,我们使用简单工厂模式解决了入口不统一的问题,然后使用工厂模式解决了修改地点不统一的问题

策略模式(Strategy)(Context):

简单工厂的定义

简单/简易工厂并不是一个设计模式, 更多是一个编程习惯. 但是使用的非常广泛.

简单工厂类图:

web前端 10

这个很简单, 就不解释了. 

简单工厂就到这, 下面要讲两个重量级的工厂模式.

抽象工厂模式

一般来说,抽象工厂在大型项目的使用更多,大概的思路是在父类里面设计好接口(没有具体实现),具体的实现等到了子类再重写.

这里借用一个张容铭的<JavaScript设计模式>的一个例子:

var Car = function(){};
Car.prototype = {
    getPrice:function(){ throw new Error("抽象方法不能调用")},
    getSpeed:function(){ throw new Error("抽象方法不能调用")}
};
//这里使用Object.create()继承,子类到父类中会多一个中间过渡函数Temp(){};防止在子类的prototype覆盖父类;
aBMW = Object.create(Car.prototype);

aBMW.getPrice();  // 抽象方法不能调用
aBMW.getPrice = function(){
    console.log("I am getting price");
};
aBMW.getPrice(); //I am getting price

父类定义好接口,具体实现延迟到子类才实现.

所以总结来说:

简单工厂模式解决了入口不统一的问题,

工厂模式解决了修改地点不统一的问题,

抽象工厂模式解决了子类实现不规范的问题。

目前我们新改版的移动端表单块逻辑和渲染分离,也类似于把一个表单页面抽离成一个工厂,工厂里面有二十多个不同的控件,每个控件去继承表单这个类。

 

 

 

1)封装算法,可相互替换

用C#/.NET Core实现简单工厂

Pizza父类:

web前端 11web前端 12

using System;
using System.Collections.Generic;

namespace SimpleFactory.Pizzas
{
    public abstract class Pizza
    {
        public string Name { get; protected set; }
        public string Dough { get; protected set; }
        public string Sauce { get; protected set; }
        protected List<string> Toppings = new List<string>();

        public void Prepare()
        {
            Console.WriteLine($"Preparing: {Name}");
            Console.WriteLine($"Tossing: {Dough}");
            Console.WriteLine($"Adding sauce: {Sauce}");
            Console.WriteLine("Adding toppings: ");
            Toppings.ForEach(x => Console.WriteLine($"  {x}"));
        }

        public void Bake()
        {
            Console.WriteLine("Bake for 25 minutes");
        }

        public void Cut()
        {
            Console.WriteLine("Cutting the pizza into diagnol slices");
        }

        public void Box()
        {
            Console.WriteLine("Placing pizza in official PizzaStore box......");
        }
    }
}

View Code

各种Pizza:

web前端 13web前端 14

namespace SimpleFactory.Pizzas
{
    public class CheesePizza: Pizza
    {
        public CheesePizza()
        {
            Name = "Cheese Pizza";
            Dough = "Think Dough";
            Sauce = "Salad";
            Toppings.Add("Grated Reggiano Cheese");
        }
    }
}

namespace SimpleFactory.Pizzas
{
    public class ClamPizza: Pizza
    {
        public ClamPizza()
        {
            Name = "Clam Pizza";
            Sauce = "Tomato sauce";
            Dough = "Soft dough";
            Toppings.Add("Shrimp meat");
        }
    }
}

namespace SimpleFactory.Pizzas
{
    public class PepperoniPizza: Pizza
    {
        public PepperoniPizza()
        {
            Name = "Pepperoni Pizza";
            Dough = "Thin dough";
            Sauce = "Black pepper";
            Toppings.Add("Beef Granules");
            Toppings.Add("Niblet");
        }
    }
}

View Code

简单工厂:

using SimpleFactory.Pizzas;

namespace SimpleFactory
{
    public class SimplePizzaFactory
    {
        public Pizza CreatePizza(string type)
        {
            Pizza pizza = null;
            switch (type)
            {
                case "cheese":
                    pizza = new CheesePizza();
                    break;
                case "pepperoni":
                    pizza = new PepperoniPizza();
                    break;
                case "clam":
                    pizza = new ClamPizza();
                    break;
            }

            return pizza;
        }
    }
}

PizzaStore:

using SimpleFactory.Pizzas;

namespace SimpleFactory
{
    public class PizzaStore
    {
        private readonly SimplePizzaFactory _factory;

        public PizzaStore(SimplePizzaFactory factory)
        {
            _factory = factory;
        }

        public Pizza OrderPizza(string type)
        {
            var pizza = _factory.CreatePizza(type);
            pizza.Prepare();
            pizza.Bake();
            pizza.Cut();
            pizza.Box();
            return pizza;
        }
    }
}

测试运行:

using System;

namespace SimpleFactory
{
    class Program
    {
        static void Main(string[] args)
        {
            var pizzaStore = new PizzaStore(new SimplePizzaFactory());
            var cheesePizza = pizzaStore.OrderPizza("cheese");
            Console.WriteLine();
            var clamPizza = pizzaStore.OrderPizza("pepperoni");
            Console.ReadKey();
        }
    }
}

web前端 15

 

2)适用于多种算法可互相替换使用。可结合工厂模式,根据传入参数在构造函数中生成具体算法对象。最终返回计算结果。

需求变更 – 授权连锁披萨店

 披萨店开的很好, 所以老板在全国各地开授权连锁分店了,
而每个地点的分店根据当地居民的口味, 它们所提供的披萨种类可能会不同.

例如纽约和芝加哥和加利福尼亚的就有可能不同.

针对这个需求, 我们可能会想到的第一种办法就是:
把SimplePizzaFactory抽取出来, 分别建立三个地点的工厂,
然后根据地点把相应的工厂组合到PizzaStore

web前端 16

代码是这样的:

纽约:

web前端 17

芝加哥:

web前端 18

因为个连锁店分布在各地, 老板想做质量管控: 做披萨的基本工序应该是一样的,
但是针对某种披萨各地可以有不同的风格做法.

所以我们把createPizza()方法放回到PizzaStore, 但这次它是抽象方法,
然后各地都会创建自己的PIzzaStore:

web前端 19

下面是纽约和芝加哥的披萨店:

web前端 20

针对每种披萨, 纽约和芝加哥可能会有自己风格具体实现的披萨.

orderPizza()方法是在父类/抽象类里面实现的, 这里的披萨还是抽象的,
所以它并不知道是PizzaStore的哪个子类来做的披萨.

代码运行的时候, orderPizza()会调用createPizza()方法,
PizzaStore的某个子类肯定会对此负责.

所以你哪个地方的PizzaStore, 就会决定产出的是哪个地方特产的披萨.

 

下面就创建PizzaStore, 例如纽约的:

web前端 21

其他地点的都差不多, 就不贴图了.

装饰模式(Decorator):

如何声明一个工厂方法

还是看这张图:

web前端 22

抽象的PizzaStore把订购披萨的固定工序orderPizza()放在了抽象类里面.

创建披萨createPizza()方法是在各地的披萨店里做实现.

用一行代码来解释工厂方法就是:

web前端 23

工厂方法是让其子类具体来实现对象创建的工作.
这样就把父类中的客户代码和子类的创建对象部分的代码解耦了.

 

上面工作做的挺好, 但是还差一件事….披萨.

首先抽象父类:

web前端 24

里面定义了调味料和工序

然后具体的披萨:

纽约的奶酪披萨

web前端 25

芝加哥的奶酪披萨

web前端 26

最后运行一下:

web前端 27

web前端 28

 

1)动态的给对象添加额外的职责

工厂方法模式

所有的工厂模式都会封装对象的创建过程,
而工厂方法模式把对象创建的动作交给了子类, 并让它决定创建哪些对象.

创建者:

web前端 29

 

产品:

web前端 30

看看另外一种结构 — 并行的类结构:

web前端 31

 

工厂方法模式的定义:

工厂方法模式定义了一个创建对象的接口,
但是让子类来决定具体创建的是哪一个对象. 工厂方法让一个类延迟实例化,
直到子类的出现.

web前端 32

左边是产品, 所有具体的产品都应该继承于同一个父类/接口.

右边的Creator类里面包含所有方法的实现除了抽象的工厂方法.
这个抽象的工厂方法在Creator的子类里面必须进行实现,
产品就是在子类具体实现的工厂方法里面创造出来的.

 

2)适用于要对一个对象的某些操作前后进行一些附加职责的时候,而且这些职责是变化(有/无
先/后)的。而且根据开闭原则,在扩展功能的时候优先思考装饰模式

设计原则 — 应该依赖于抽象, 而不依赖于具体的类

这就是著名的: DIP (Dependency Inversion
Principle) 依赖反转原则
.

进一步解释就是: 高级别的组件不应该依赖于低级别的组件,
它们都应该依赖于抽线
.

高级别组件, 就是它有一组行为定义在另外一堆低级别的组件里面了.

例如PizzaStore就是高级别的, 具体的披萨就是低级别的.

应该该设计原则后:

web前端 33

这时它们都依赖于抽象的披萨父类了.

代理模式(Proxy)

实现该原则的三点指导建议

  • 没有变量引用具体的类(可已使用工厂代替创建这个具体的类)
  • 没有类派生于具体的类(派生于它就依赖于它)
  • 不去重写(override)其任一父类的已实现方法(如果重写了,
    那么这个类并不适合作为起始的抽象类,
    因为基类里面的方法本应该是共享与所有子类的)

和其它原则一样, 只是尽力去按照这三点建议去执行, 并不是必须一直要这么做.

1)控制一个对象的访问

C#/.NET Core的代码实现

各种pizza:

web前端 34web前端 35

namespace FactoryMethodPattern.Pizzas
{
    public class ChicagoCheesePizza : Pizza
    {
        public ChicagoCheesePizza()
        {
            Name = "Chicago Cheese Pizza";
            Dough = "Think Dough 1";
            Sauce = "Salad 1";
            Toppings.Add("Grated Reggiano Cheese 1");
        }
    }
}

namespace FactoryMethodPattern.Pizzas
{
    public class ChicagoClamPizza : Pizza
    {
        public ChicagoClamPizza()
        {
            Name = "Chicago Clam Pizza";
            Sauce = "Tomato sauce 1";
            Dough = "Soft dough 1";
            Toppings.Add("Shrimp meat 1");
        }
    }
}

namespace FactoryMethodPattern.Pizzas
{
    public class ChicagoPepperoniPizza : Pizza
    {
        public ChicagoPepperoniPizza()
        {
            Name = "Chicago Pepperoni Pizza";
            Dough = "Thin dough 1";
            Sauce = "Black pepper 1";
            Toppings.Add("Beef Granules 1");
            Toppings.Add("Niblet 1");
        }
    }
}

namespace FactoryMethodPattern.Pizzas
{
    public class NYCheesePizza: Pizza
    {
        public NYCheesePizza()
        {
            Name = "NY Cheese Pizza";
            Dough = "Think Dough 2";
            Sauce = "Salad 2";
            Toppings.Add("Grated Reggiano Cheese 2");
        }
    }
}

namespace FactoryMethodPattern.Pizzas
{
    public class NYClamPizza: Pizza
    {
        public NYClamPizza()
        {
            Name = "NY  Clam Pizza";
            Sauce = "Tomato sauce 2";
            Dough = "Soft dough 2";
            Toppings.Add("Shrimp meat 2");
        }
    }
}

namespace FactoryMethodPattern.Pizzas
{
    public class NYPepperoniPizza: Pizza
    {
        public NYPepperoniPizza()
        {
            Name = "NY Pepperoni Pizza";
            Dough = "Thin dough 2";
            Sauce = "Black pepper 2";
            Toppings.Add("Beef Granules 2");
            Toppings.Add("Niblet 2");
        }
    }
}

View Code

披萨店抽象父类:

using FactoryMethodPattern.Pizzas;

namespace FactoryMethodPattern
{
    public abstract class PizzaStore
    {
        public Pizza OrderPizza(string type)
        {
            var pizza = CreatePizza(type);
            pizza.Prepare();
            pizza.Bake();
            pizza.Cut();
            pizza.Box();
            return pizza;
        }

        protected abstract Pizza CreatePizza(string type);
    }
}

Chicago披萨店:

using FactoryMethodPattern.Pizzas;

namespace FactoryMethodPattern
{
    public class ChicagoPizzaStore: PizzaStore
    {
        protected override Pizza CreatePizza(string type)
        {
            Pizza pizza = null;
            switch (type)
            {
                case "cheese":
                    pizza = new ChicagoCheesePizza();
                    break;
                case "pepperoni":
                    pizza = new ChicagoPepperoniPizza();
                    break;
                case "clam":
                    pizza = new ChicagoClamPizza();
                    break;
            }

            return pizza;
        }
    }
}

纽约披萨店:

web前端 36web前端 37

using FactoryMethodPattern.Pizzas;

namespace FactoryMethodPattern
{
    public class NYPizzaStore : PizzaStore
    {
        protected override Pizza CreatePizza(string type)
        {
            Pizza pizza = null;
            switch (type)
            {
                case "cheese":
                    pizza = new NYCheesePizza();
                    break;
                case "pepperoni":
                    pizza = new NYPepperoniPizza();
                    break;
                case "clam":
                    pizza = new NYClamPizza();
                    break;
            }

            return pizza;
        }
    }
}

View Code

测试运行:

using System;

namespace FactoryMethodPattern
{
    class Program
    {
        static void Main(string[] args)
        {
            var nyStore = new NYPizzaStore();
            var chicagoStore = new ChicagoPizzaStore();

            var pizza = nyStore.OrderPizza("cheese");
            Console.WriteLine($"Ordered a {pizza.Name} in NY");
            Console.WriteLine();
            var pizza2 = chicagoStore.OrderPizza("cheese");
            Console.WriteLine($"Ordered a {pizza2.Name} in Chicago");

            Console.ReadKey();
        }
    }
}

web前端 38

 

2)应用于要为对象添加权限限制或者加锁,添加访问计数等附加职责。访问对象一定要先经过代理。

工厂方法模式(Factory method):

1)定义接口使实例化的工作延迟到子类

2)工厂模式是在工厂内部用switch等方式判断创建什么对象。工厂方法把这个问题提前了,用户传进来的不是switch的参数而是具体要使用的哪种工厂。问题前移~

原型模式(Prototype):

1)通过拷贝创建新对象

2)原型模式和工厂模式相同,是创建对象的方式,通过拷贝创建对象,创建者不用知道创建的细节,最重要的是可以得到对象运行时的状态。【这里设计了深浅拷贝,java
clone()方法原理是值复制,引用指向同一内容,所以浅拷贝并不能复制对象。实现深拷贝一种是在set方法里创建新的对象,一种是在clone方法里面再次调用类成员的clone】

模版模式(Template):

1)提炼骨架,子类实现细节

2)适用于流程相同但具体实现不同的case,如果说策略模式给的是一种算法的可替换,那么模版模式更像是一组解决方案,并且将整个流程提出的感觉。

外观模式(Facade):

1)提炼接口,封装部分,将代码分块

2)适用于:a.分割表示层,逻辑层和数据层
b.对于复杂的老旧的逻辑块封装一层facade可以减少依赖,提炼接口也可以更好的分工。

建造者模式(Builder):

1)相较于工厂模式,监督创建细节

2)建造者模式也是创建对象的模式,被创建的对象有相同的创造流程和不同的实现;监督者接受创建的具体对象并且执行整个流程并返回执行之后的创建的具体对象。即调用放知道要创建什么样的产品但是无需知道创建过程,且保证所有创建步骤都进行。

观察者模式(Observer):

1)解决一对多的依赖关系的变化引发修改问题。

2)观察者维护观察对象数组,当观察者发生变化的时候循环执行所有与之依赖的对象的更改方法,完成更新。

抽象工厂模式(Abstract Factory):

1)解决不同“系列”对象的创建

2)不同于工厂模式可以根据参数决定创建的对象。也不像工厂方法模式,根据创建的具体工厂,决定返回的对象。抽象工厂主要解决的是“系列”的切换,每个工厂可以创建一个系列产品的各个组件。有利于“系列间的切换,并且将创建过程与客户端分离。

状态模式(Status):

1)将状态变化的逻辑抽离,是状态的转化成为每个具体状态类自己的方法,易扩展

2)适用于有大量ifelse或者swich判断状态变化代码段的优化,使类的职责单一,使扩展状态更加容易。

适配器模式(Adapter):

1)解决接口不兼容问题

2)适用于使用原有的接口,又不想改变原有接口或实现的结构(在设计初期不应考虑)

备忘录模式(Memento):

1)用于恢复原来保存的状态

2)适用于保存进度或者report的程序设计。值得一提的是要保存的类的备忘录类与其并不存在关联关系,而是通过另一个管理者类控制,减轻了他们之间的耦合度。

组合模式(Component):

1)实现树结构,统一管理

2)组合模式适用于管理整体与部分,通过都继承同一个抽象类,统一相同的方法,通过调用“根”结构的方法,使所有部分完成操作。【就是树结构的实现】

迭代器模式(Iterator):

1)实现对不同类型数据的不同方式的遍历

2)java中的各种集合列表等数据结构都实现了iterator,也就是可以使用while(xxx.iterator().hasNext())进行遍历,当然foreach也是适用于iterator的实现类。当然我们也可以通过实现iterator方法来改变遍历方式。

单例模式(Singleton):

1)保证一个类只被实例化一次

2)常见的几种实现方法:双重校验锁;synchronize保证线程安全,static XX
instance=new XX()装载时实例化,用enum实现单例。

桥接模式(Bridge):

1)将抽象分离,使其独立变化

2)适用于庞大的继承结构,或者可以根据多种方式建立继承关系的设计。涉及到聚合优于继承原则,继承结构是紧耦合的,父类变化子类受到影响,而聚合却不是。将某一特性或者说是一层继承的共性提炼出来聚合到父类完成解耦。另一种判断是用isa和hasa判断是否有可以解耦的部分。

命令模式(Commond):

1)将请求者和执行者隔离,通过管理者管理命令的执行。

2)其实命令模式的使用场景很局限,因为我们一直奉行类是一个名词而不是一个操作。但是命令模式也有其好处就是可以对操作进行管理。通过管理者维护命令队列实现决定何时执行命令,记录执行的命令,撤销已执行命令等操作。

责任链模式(Chain of Responsibility):

1)请求方与执行方解耦

2)适用于代码中有层级关系的ifelse结构。父类包含自己的引用,子类将引用指向下一个责任人(另一个子类),由于都实现了同样的方法,所以若子类1不能处理则调用下一个责任人的处理方法。对于调用方只需知道第一责任人是谁就可以了。

中介者模式(Mediator):

1)减少类与类之间的依赖,把类之间的交互由中介者完成

2)适用于一组对象以定义良好的但是复杂的方式进行通讯,比如Form和控件,Form就是中介者,每个控件可能会其他控件但不通过直接依赖实现。但是一般不考虑这种设计模式,因为中介者本身是一个低内聚高耦合的结构,虽然类的修改方便了,但是中介者的改动不容易控制。

享元模式(FlyWeight):

1)通过共享实例减少细粒度实例的个数

2)适用于要new大量细粒度的类(除了几个参数其他都是相同的),比如棋子。将不可共享的参数外部化,在使用的时候作为参数传入。减少存储开销。

解释器模式(Interpreter):

1)定义一种新的文法解读

2)适用于自己要定义一种通用且常用的规则解决一些常见的问题,比如正则表达式,乐谱翻译器等。

访问者模式(Visitor):

1)将操作方法从类中抽离,使操作扩展性强。

2)访问者模式是有条件苛刻,所以应用场景较少。适用于某类的子类不会发生改变且数量不多的情况,且操作存在差异。比如男人和女人。这样每种操作只需要实现子类数量个实现就可以了。扩展操作的时候只需添加一个visitor的子类,实现对应元素类的子类的方法。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 澳门新葡亰官网app 版权所有