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

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

定义一个策略接口类。

public interface UserCache {public void cache();}

public class LRUCache implements UserCache{@Overridepublic void cache() {System.out.println("LRU算法");}}

public class FIFOCache implements UserCache{@Overridepublic 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 否则的话，那么缺少什么就需要进行编码调整，所以里面有各种的设计模式来提升程序的拓展性。

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