【设计模式】聊聊策略模式

策略模式的本质是为了消除if 、else代码，提供拓展点，对拓展开放，对修改关闭，也就是说我们开发一个功能的时候，要尽量的采用设计模式进行将不变的东西进行抽取出来，将变化的东西进行隔离开来，这样不仅仅可以减少bug，也可以提高开发效率。

策略的整体是策略类的定义、创建、使用三部分。

定义一个策略接口类。

public interface UserCache {

    public void cache();

}

public class LRUCache implements UserCache{

    @Override
    public void cache() {
        System.out.println("LRU算法");
    }

}

public class FIFOCache implements UserCache{

    @Override
    public void cache() {
        System.out.println("FIFO cache");
    }
}

public class CacheContext {

    private UserCache userCache;

    public CacheContext(UserCache userCache) {
        this.userCache = userCache;
    }


    public void run() {
        userCache.cache();
    }

}

测试类

        LRUCache lruCache = new LRUCache();
        CacheContext cacheContext = new CacheContext(lruCache);
        cacheContext.run();

可以发现通过将不同的策略进行抽取出来，利用面向接口编程的方式，进行编程。其实也可以不利用context，也可以利用查表法进行编程。

public class CacheFactory {
    
    private static Map<String,UserCache> cache = new ConcurrentHashMap<>();
    
    static {
        cache.put("LRU",new LRUCache());
        cache.put("LRU",new LRUCache());
    }
    
    public static void run (String cacheType) {
        if (Objects.isNull(cacheType)) {
            throw new RuntimeException("");
        }
        UserCache userCache = cache.get(cacheType);
        userCache.cache();
    }
    
}

其实在spring mvc中，比如解析不同的数据结构，xml、json等格式，都是进行抽象出高纬度的接口，然后根据配置进行查找对应的解析器进行处理，我们不一定要参考GOF的设计模式进行设计，一定要结合自身的业务实际来设计对象结构和逻辑，否则就不能灵活套用。

在说一个就是平时开发中为什么很少使用到设计模式，其实我们开发的大部分业务都不具备框架级别的可复用性，大多都是需求，一次性的，所以很少使用到。但是框架不一样，它需要考虑更重的适配性，不能说我都if、else 否则的话，那么缺少什么就需要进行编码调整，所以里面有各种的设计模式来提升程序的拓展性。

那么平时我们如何将学习到的设计模式使用到项目中，其实可以根据现有业务考虑，将不变的东西进行抽取，改变的东西进行拓展。但是也不要过度设计，否则为了编码的可拓展性，降低了可读性。设计一个精心的高拓展架构，其实本身就是一种权衡。架构设计亦是如此，软件设计也是如此。架构设计平衡的是在高性能、稳定性、可拓展上的权衡、软件设计则是在可读性、可拓展性、维护性权衡。