策略模式+工厂模式+map

策略模式+工厂模式+map 整理 项目中的switch case/if
转载:文章大佬写的文章 (如有侵权,请联系我,会立即删除)

接手新任务:接入第三家存证机构,看之前的代码使用了swith case判断使用哪家存证机构,每家存证机构的实现逻辑不一样 代码的坏味道:多层swich case。多层swich case不好维护,是时候应该重构了,

优化前的代码
为了便于理解,举个没有业务逻辑的例子,基于这个例子上进行优化。 现在是12:47,举个饭后吃水果的例子哈哈哈(逃 假设我们可以选择的水果有香蕉、西瓜和苹果。吃香蕉的话我们得先剥皮,吃西瓜的话得先用水果刀切一下,如果是苹果的话就直接吃了。将这个场景转化为代码:

	public class EatFruit {
    private static final String APPLE = "apple";
    private static final String BANANA = "banana";
    private static final String WATERMELON = "watermelon";

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        //选择的水果种类
        String fruitType = scanner.nextLine();

        switch (fruitType) {
            case APPLE:
                eatApple();
                break;
            case BANANA:
                eatBanana();
                break;
            case WATERMELON:
                eatWatermelon();
                break;
        }
    }

    private static void eatBanana() {
        System.out.println("吃香蕉了,需要先剥下皮");
    }

    private static void eatApple() {
        System.out.println("是苹果,可以直接吃");
    }

    private static void eatWatermelon() {
        System.out.println("吃西瓜了,但是还得弄把水果刀切一下先");
    }
}

这个例子代码量不是很大,但是实际项目中的场景肯定没有这么简单,多重swich case不好维护,并且万一又加了一样水果,还得继续加一层case…

赶紧优化
很容易想到策略模式(简单的理解就是多态),水果都有吃的一个动作,但是每种水果的吃法不一样
使用策略模式进行优化

Fruit.java

public interface Fruit {
    void eat();
}

Apple.java

public class Apple implements Fruit {
    @Override
    public void eat() {
        System.out.println("是苹果,可以直接吃");
    }
}

Banana.java

public class Banana implements Fruit {
    @Override
    public void eat() {
        System.out.println("吃香蕉了,需要先剥下皮");
    }
}

Watermelon.java

public class Watermelon implements Fruit {
    @Override
    public void eat() {
        System.out.println("吃西瓜了,但是还得弄把水果刀切一下先");
    }
}

但是发现即使用了策略模式也难逃类型判断 EatFruit.java

	public class EatFruit {
    private static final String APPLE = "apple";
    private static final String BANANA = "banana";
    private static final String WATERMELON = "watermelon";

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        //选择的水果种类
        String fruitType = scanner.nextLine();
        Fruit fruit = null;

        switch (fruitType) {
            case APPLE:
                fruit = new Apple();
                break;
            case BANANA:
                fruit = new Banana();
                break;
            case WATERMELON:
                fruit = new Watermelon();
                break;
        }

        fruit.eat();
    }
	}

使用策略模式具有良好的扩展性,兵来将挡,再给我添加十种水果都不怕,水果种类太多会使水果的实现类暴增。现在来一种水果无需在原先的业务类(EatFruit)里修改很多的代码逻辑,只要实现接口并加个条件判断就好了。但是使用策略模式时,我们需要知道具体的实现类,具体的实现类需要对外暴露

使用工厂模式
将类型判断放到工厂类中 工厂模式:在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象,这里共同的接口就是Fruit。粗暴的讲,工厂模式就是把创建同一类型对象逻辑写在了一个方法里 FruitFactory .java

	public class FruitFactory {
    public static Fruit getFruit(String fruitType) {
        if ("apple".equals(fruitType)) {
            return new Apple();
        }

        if ("banana".equals(fruitType)) {
            return new Banana();
        }

        return new Watermelon();
    }
	}

EatFruit .java

public class EatFruit {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        //选择的水果种类
        String fruitType = scanner.nextLine();
        Fruit fruit = FruitFactory.getFruit(fruitType);
        fruit.eat();
    }
}

到现在为止EatFruit中的业务代码已经很清晰了。 使用工厂模式具有良好的封装性,这下妈妈再也不用关系创建类的过程,甚至连创建的实际类的都无需关心,实现了解耦,实际类的修改变化都不会影响上层业务
但是工厂类中还是有很多if的,革命尚未成功,仍需要进行优化。

map奥特曼来了

FruitFactory.java

public class FruitFactory {
    private static Map<String, Fruit> fruitMap = new HashMap<>();

    static {
        fruitMap.put("apple", new Apple());
        fruitMap.put("banana", new Banana());
        fruitMap.put("watermelon", new Watermelon());
    }

    public static Fruit getFruit(String fruitType) {
       return fruitMap.get(fruitType);
    }
}

通过使用map,fruitType与进行一一映射,和条件判断说byebye~,代码也很优雅 最终项目结构类图:

有网友评论可以用反射替代map,如果传进来的是Class类型的值就可以用反射。用反射的好处是在添加多种水果,工厂类的代码都无需进行变动 通过反射替代map: FruitFactory2.java

public class FruitFactory2 {
    public static <T extends Fruit> T getFruit(Class<T> fruitClass) throws IllegalAccessException, InstantiationException {
        return fruitClass.newInstance();
    }
}
  • 6
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
工厂模式中使用map可以提供一种更优雅的方式来进行类型判断和对象创建。通过使用map,我们可以将不同的类型和对应的对象进行一一映射,从而消除了繁琐的条件判断语句,使代码更加简洁和可读性更高。在上述提供的代码示例中,通过使用工厂模式map,我们可以将不同水果类型与相应的水果对象进行映射。具体实现步骤如下: 1. 创建一个工厂类FruitFactory,该类中包含一个静态方法getFruit,参数为fruitType,用于获取对应类型的水果对象。 2. 在getFruit方法内部,使用map来存储不同类型的水果对象。例如,将"apple"和Apple对象进行映射,将"banana"和Banana对象进行映射,将其他类型与Watermelon对象进行映射。 3. 在客户端代码中,通过调用FruitFactory.getFruit(fruitType)方法,传入用户选择的水果类型,即可获取对应类型的水果对象。 4. 最后,可以调用水果对象的相应方法,如eat()方法,来实现相应的功能。 通过使用工厂模式map,我们可以将对象的创建逻辑封装在工厂类中,使得客户端代码不需要关心具体的对象创建细节,只需要调用工厂方法并传入相应的参数即可获取到对应的对象。这种方式可以提高代码的可维护性和扩展性,使得代码更加清晰和易于理解。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [策略模式+工厂模式+map](https://blog.csdn.net/qq_31217363/article/details/106012287)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值