一句话总结殊途同归的设计模式:工厂模式=?策略模式=?模版方法模式

一句话总结殊途同归的设计模式:工厂模式=?策略模式=?模版方法模式虽然不同的设计模式解决的问题各不相同,但从一个更高的抽象层次来看,它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式,以及这些模式所遵循的设计原则。

这是设计模式系列的第一篇,系列文章目录如下:

  1. 一句话总结殊途同归的设计模式:工厂模式=?策略模式=?模版方法模式

  2. 使用组合的设计模式 —— 美颜相机中的装饰者模式

  3. 使用组合的设计模式 —— 找对象要用的远程代理模式

  4. 用设计模式去掉没必要的状态变量 —— 状态模式

虽然不同的设计模式解决的问题各不相同,但从一个更高的抽象层次来看,它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式,以及这些模式所遵循的设计原则。先用一句话总结它们的共同点:

它们增加了一层抽象将变化封装起来,然后对抽象编程,并利用多态应对变化。

应用这些设计模式的项目实战可以移步下面的链接:

  1. 再也不要和产品经理吵架了——Android自定义单选按钮
  2. 这样写代码就能和产品经理成为好朋友——策略模式实战

工厂模式

1. 变化是什么

对工厂模式来说,变化就是构建对象的方式,举个例子:

public class PizzaStore{
    public Pizza orderPizza(String type){
        Pizza pizza ;
    
        //构建具体pizza对象
        if(type.equals("cheese")){
            pizza = new CheesePizza();
        }else if(type.equals("bacon")){
            pizza = new BaconPizza();
        }
    
        //使用pizza对象
        pizza.prepare();
        pizza.bake();
        return pizza ;
    }
}

抽象的反义词是具体,对于工厂模式,具体就是用new来构建对象。这样做的后果是PizzaStore不仅需要引入具体的Pizza类,而且和构建Pizza的细节耦合在一起。

如果PizzaStore一辈子只做这两种Pizza,上面的代码就很好,不需要重构。但如果需要新增Pizza类型,就不得不修改orderPizza(),向其中增加if-else

2. 如何应对变化

通过将变化封装在一层新的抽象中,实现了上层代码和变化的隔离,达到解耦的目的。对于工厂模式来说,新建的抽象叫做工厂,它将对象的构建和对象的使用分隔开,让使用对象的代码不依赖于构建对象的细节。

解耦的好处是:“当变化发生时上层代码不需要改动”,这句话也可以表达成:“在不修改既有代码的情况下扩展功能”。这就是著名的 “开闭原则”

  • “对修改关闭”的意思是:当需要为类扩展功能时,不要想着去修改类的既有代码,这是不允许的! 为啥不允许?因为既有代码是由数位程序员的努力,历经了多个版本的迭代,好不容易才得到的正确代码。其中蕴含着博大精深的知识,和你不曾了解的细节,修改它一定会出bug的!
  • “对扩展开放”的意思是:类的代码应该具备良好的抽象,使得扩展类的时候,不需要修改类的既有代码。

现实的问题来了,如果项目中的既有类不具备扩展性,甚至是牵一发动全身的那种类。在一个时间较紧的迭代中需要往里添加新功能,你会怎么做?是违背“对修改关闭”,还是咬牙重构?(欢迎讨论~~)

3. 三种封装变化方式

  1. 简单工厂模式

既然目的是消除orderPizza()中构建具体pizza的细节,那最直接的做法是,将他们提取出来放到另一个类中:

public class PizzaFactory{
    public static Pizza createPizza(String type){
        Pizza pizza ;
        if(type.equals("cheese")){
            pizza = new CheesePizza();
        }else if(type.equals("bacon")){
            pizza = new BaconPizza();
        }
        return pizza ;
    }
}

然后使用Pizza的代码就变成:

public class PizzaStore{
    public Pizza orderPizza(String type){
        Pizza pizza = PizzaFactory.createPizza(type);
        pizza.prepare();
        pizza.bake();
        return pizza ;
    }
}

等等,这和我们平时将一段常用代码抽离出来放到Util类中有什么区别吗?

是的,没有任何区别。从严格意义上说,这不是一个设计模式,更像是一种编程习惯。虽然只是代码搬家,但这种习惯的好处是:它隐藏了构建对象的细节,因为构建对象是经常会发生变化的,所以它还封装了变化,最后它还可以被复用,比如菜单类也需要构建 pizza 对象并获取他们的价格。

使用静态方法是这类封装常用的技巧,它的好处是不需要新建工厂对象就可以实现调用,但缺点是不具备扩展性(静态方法不能被重写)。

  1. 工厂方法模式

简单工厂模式中,工厂能够构建几种对象是在编译之前就定义好的,如果想要新增另一种新对象,必须修改既有的工厂类。这不符合开闭原则。 所以简单工厂模式对于新增对象类型这个场景来说显得不够有弹性。

有没有办法不修改既有类就新增对象类型?

工厂方法模式就可以做到,因为它采用了继承:

//抽象pizza店
public abstract class PizzaStore{
    public Pizza orderPizza(String type){
        Pizza pizza = createPizza(type);
        pizza.prepare();
        pizza.bake();
        return pizza ;
    }
    //不同地区的pizza店可以推出地方特色的pizza
    protected abstract Pizza createPizza(String type) ;
}

//A商店提供芝士和培根两种pizza
public class PizzaStoreA extends PizzaStore{
    @Override
    protected Pizza createPizza(String type){
        Pizza pizza ;
        if(type.equals("cheese")){
            pizza = new CheesePizza();
        }else if(type.equals("bacon")){
            pizza = new BaconPizza();
        }
        return pizza ;
    }
}

简单工厂模式将构建对象的细节封装在一个静态方法中(静态方法无法被继承),而工厂方法模式将其封装在一个抽象方法中,这样子类可以通过重写抽象方法新增 pizza。

现在是介绍另一个设计原则的绝佳时机,它就是 “依赖倒置原则” :上层组件不能依赖下层组件,并且它们都不能依赖具体,而应该依赖抽象。

上面的例子中PizzaStore是上层组件,CheesePizza是下层组件,如果直接在PizzaStore中构建CheesePizza就违反了依赖倒置原则,经过工厂模式的重构,PizzaStore依赖于Pizza这个抽象,同时CheesePizza也依赖于这个抽象。所以违反依赖倒置会让代码缺乏弹性,不易扩展。

Android 中RecyclerView.Adapter就运用了工厂方法模式:

public abstract static class Adapter<VH extends ViewHolder> {
    //封装了各式各样ViewHolder的构建细节,延迟实现构建细节到子类中
    public abstract VH onCreateViewHolder(ViewGroup parent, int viewType);
}
  1. 抽象工厂模式

如果需要构建一组对象怎么办?

抽象工厂模式用来处理这种情况,它将构建一组对象的细节封装在一个接口中:

//抽象原料工厂(原材料构建者)
public interface IngredientFactory{
    void Flour createFlour()void Sause createSause();
}

//原材料使用者
public class Pizza{
    private Flour flour;
    private Sause sause;
    //使用组合持有构建者
    private IngredientFactory factory;
    
    //注入一个具体构建者
    //同一种pizza,在不同地区可能会有不同口味
    //那是因为虽然用的是同类原材料(抽象),当产地不同味道就不同(具体)
    public Pizza(IngredientFactory factory){
        this.factory = factory;
    }
    
    //使用具体工厂构建原材料(发生多态的地方)
    public void prepare(){
        flour = factory.createFlour();
        sause = factory.createSause();
    }
    
    public void bake(){}
    public void cut(){}
}

//具体工厂
public class FactoryA implements IngredientFactory{
    public Flour createFlour(){
        return new FlourA();
    }
    
    public Sause createSause(){
        return new SauseA();
    }
}

//构建pizza的时候传入具体工厂
public class PizzaStoreA extends PizzaStore{
    @Override
    protected Pizza createPizza(String type){
        Pizza pizza ;
        FactoryA factory = new FactoryA();
        if(type.equals("cheese")){
            pizza = new CheesePizza(factory);
        }else if(type.equals("bacon")){
            pizza = new BaconPizza(factory);
        }
        return pizza ;
    }
}

如果地区B开了一家新pizza店,只需要新建FactoryB并在其中定义地区B原材料的构建方式,然后传入Pizza类,整个过程不需要修改Pizza基类。

抽象工厂模式 和 工厂方法模式 的区别在于:

  1. 前者适用于构建多个对象,并且使用组合。
  2. 后者适用于构建单个对象,并且使用继承。

策略模式

1. 变化是什么

对策略模式来说,变化就是一组行为,举个例子:

public class Robot{
    public void onStart(){
        goWorkAt9Am();
    }
    public void onStop(){
        goHomeAt9Pm();
    }
}

机器人每天早上9点工作。晚上9点回家。公司推出了两款新产品,一款早上8点开始工作,9点回家。另一款早上9点工作,10点回家。

面对这样的行为变化,继承是可以解决问题的,不过你需要新建两个Robot的子类,重载一个子类的onStart(),重载另一个子类的onStop()。如果每次行为变更都通过继承来解决,那子类的数量就会越来越多(膨胀的子类)。更重要的是,添加增子类是在编译时新增行为, 有没有办法可以在运行时动态的修改行为?

2. 如何应对变化

通过将变化的行为封装在接口中,就可以实现动态修改:

//抽象行为
public interface Action{
    void doOnStart();
    void doOnStop();
}

public class Robot{
    //使用组合持有抽象行为
    private Action action;
    //动态改变行为
    public void setAction(Action action){
        this.action = action;
    }
    
    public void onStart(){
        if(action!=null){
            action.doOnStart();
        }
    }
    public void onStop(){
        if(action!=null){
            action.doOnStop();
        }
    }
}

//具体行为1
public class Action1 implements Action{
    public void doOnStart(){
        goWorkAt8Am();
    }
    public void doOnStop(){
        goHomeAt9Pm();
    }
}

//具体行为2
public class Action2 implements Action{
    public void doOnStart(){
        goWorkAt9Am();
    }
    public void doOnStop(){
        goHomeAt10Pm();
    }
}

//将具体行为注入行为使用者(运行时动态改变)
public class Company{
    public static void main(String[] args){
        Robot robot1 = new Robot();
        robot1.setAction(new Action1());
        robot1.setAction(new Action2());
    }
}

策略模式将具体的行为和行为的使用者隔离,这样的好处是,当行为发生变化时,行为的使用者不需要变动。

Android 中的各种监听器都采用了策略模式,比如View.setOnClickListener(),但下面这个更偏向于观察者模式,他们的区别是策略模式的意图在于动态替换行为,当第二次调用setOnClickListener()时,之前的行为被替换,而观察者模式是动态添加观察者:

public class RecyclerView{
    //使用组合持有抽象滚动行为
    private List<OnScrollListener> mScrollListeners;
    
    //抽象滚动行为
    public abstract static class OnScrollListener {
        public void onScrollStateChanged(RecyclerView recyclerView, int newState){}
        public void onScrolled(RecyclerView recyclerView, int dx, int dy){}
    }
    
    //动态修改滚动行为
    public void addOnScrollListener(OnScrollListener listener) {
        if (mScrollListeners == null) {
            mScrollListeners = new ArrayList<>();
        }
        mScrollListeners.add(listener);
    }
    
    //使用滚动行为
    void dispatchOnScrollStateChanged(int state) {
        if (mLayout != null) {
            mLayout.onScrollStateChanged(state);
        }
        onScrollStateChanged(state);

        if (mScrollListener != null) {
            mScrollListener.onScrollStateChanged(this, state);
        }
        if (mScrollListeners != null) {
            for (int i = mScrollListeners.size() - 1; i >= 0; i--) {
                mScrollListeners.get(i).onScrollStateChanged(this, state);
            }
        }
    }
}

列表滚动后的行为各不相同,所以使用抽象类将其封装起来(其实和接口是一样的)。

策略模式的实战应用可以点击这里

模版方法模式

1. 变化是什么

从严格意义上讲,模版方法模式并不能套用开篇的那句话:“它们增加了一层抽象将变化封装起来,然后对抽象编程,并利用多态应对变化”。因为如果这样说,就是在强调目的是 “应对变化” 。但模版方法的目的更像是 “复用算法”,虽然它也有应对变化的成分。

对模版方法模式来说,变化就是算法的某个步骤,举个例子:

public class View{
    public void draw(Canvas canvas) {
        ...
        // skip step 2 & 5 if possible (common case)
        if (!verticalEdges && !horizontalEdges) {
            // Step 3, draw the content
            if (!dirtyOpaque) onDraw(canvas);

            // Step 4, draw the children
            dispatchDraw(canvas);

            drawAutofilledHighlight(canvas);

            // Overlay is part of the content and draws beneath Foreground
            if (mOverlay != null && !mOverlay.isEmpty()) {
                mOverlay.getOverlayView().dispatchDraw(canvas);
            }

            // Step 6, draw decorations (foreground, scrollbars)
            onDrawForeground(canvas);

            // Step 7, draw the default focus highlight
            drawDefaultFocusHighlight(canvas);

            if (debugDraw()) {
                debugDrawFocus(canvas);
            }

            // we’re done...
            return;
        }
        ...
    }
    
    protected void dispatchDraw(Canvas canvas) { }
}

节选了View.draw()方法中的某一片段,从注释中可以看出draw()定义了一个绘图的算法框架,一共有七个步骤,所有步骤都被抽象成一个方法,其中的变化在于,每个步骤对于不同类型的View都可能是不同的。所以为了让不同View复用这套算法框架,就把它定义在了父类中,子类可以通过重写某一个步骤来定义不同的行为。

模版方法模式是一种常用的重构方法,它将子类的共用逻辑抽象到父类中,并将子类特有子逻辑设计成抽象方法供子类重写。

2. 对比

  • 模版方法模式 vs 工厂方法模式

从代码层面看,模版方法的实现方式和工厂方法模式几乎一样,都是通过子类重写父类的方法。唯一的不同是,工厂方法模式父类中的方法必须是抽象的,也就是说强制子类实现,因为子类不实现父类就无法工作。而模版方法模式父类中的方法可以是不抽象的,也就是说子类可以不实现,父类照样能工作。这种在父类中空实现的方法有一个专门的名字叫 “hook(钩子)” ,钩子的存在,可以让子类有能力对算法的流程进行控制,比如ViewGroup.onInterceptTouchEvent()

  • 模版方法模式 vs 策略模式

从产出来看,模版方法模式和策略模式是一个阵营的,因为他们产出的都是一组行为(算法),而工厂模式产出的是一个对象。但它们俩对算法的控制力不同,策略模式可以轻松的替换掉整个算法,而模版方法模式只能替换掉算法中的某个步骤。从代码层面来看,它们的实现方式也不同,策略模式使用组合,而模版方法模式使用继承。组合比继承更具有弹性,因为它可以在运行时动态的替换行为。

后续

这个系列会持续分享对其他设计模式的理解。

《Head First》是一本让我对设计模式理解升级的书,强烈推荐(本篇中工厂模式的例子摘自其中)。

今天的文章一句话总结殊途同归的设计模式:工厂模式=?策略模式=?模版方法模式分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/16345.html

(0)
编程小号编程小号

相关推荐

发表回复

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