【设计模式】聊聊策略模式
策略模式的本质是为了消除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 否则的话,那么缺少什么就需要进行编码调整,所以里面有各种的设计模式来提升程序的拓展性。
那么平时我们如何将学习到的设计模式使用到项目中,其实可以根据现有业务考虑,将不变的东西进行抽取,改变的东西进行拓展。但是也不要过度设计,否则为了编码的可拓展性,降低了可读性。设计一个精心的高拓展架构,其实本身就是一种权衡。架构设计亦是如此,软件设计也是如此。架构设计平衡的是在高性能、稳定性、可拓展上的权衡、软件设计则是在可读性、可拓展性、维护性权衡。