工厂模式的进阶用法：如何去动态的选择对象。

傷城~ 2024-03-26 20:13 28阅读 0赞

### 前言 ###

工厂设计模式可能是最常用的设计模式之一，我想大家在自己的项目中都用到过。可能你会不屑一顾，但这篇文章不仅仅是关于工厂模式的基本知识，更是讨论如何在运行时动态选择不同的方法进行执行，你们可以看看是不是和你们项目中用的一样？

### 小菜鸟的问题 ###

直接上例子说明，设计一个日志记录的功能，但是支持记录到不同的地方，例如：

*  内存中
 *  磁盘上的文件
 *  数据库
 *  百度网盘等远程存储服务

面对这么一个需求，你会怎么做呢？我们先来看看小菜鸟的做法吧。

1.  小菜鸟创建了一个`Logger`类

class Logger {
        public void log(String message, String loggerMedium) {}
    }

1.  小菜鸟想都不想，直接一通`if else`。

class Logger {
        public void log(String message, String loggerMedium) {
            if (loggerMedium.equals("MEMORY")) {
                logInMemory(message);
            } else if (loggerMedium.equals("FILE")) {
                logOnFile(message);
            } else if (loggerMedium.equals("DB")) {
                logToDB(message);
            } else if (loggerMedium.equals("REMOTE_SERVICE")) {
                logToRemote(message);
            }
        }
    
        private void logInMemory(String message) {
            // Implementation
        }
    
        private void logOnFile(String message) {
            // Implementation
        }
    
        private void logToDB(String message) {
            // Implementation
        }
    
        private void logToRemote(String message) {
            // Implementation
        }
    }

现在突然说要增加一种存储介质`FLASH_DRIVE`，就要改了这个类？不拍改错吗？也不符合“开闭原则”，而且随着存储介质变多，类也会变的很大，小菜鸟懵逼了，不知道怎么办？

### 有没有更好的方法呢？ ###

这时候小菜鸟去找你帮忙，你一顿操作，改成了下面这样：

class InMemoryLog {
        public void logToMemory(String message) {
            // Implementation
        }
    }
    
    class FileLog {
        public void logToFile(String message) {
            //Implementation
        }
    }
    
    class DBLog {
        public void logToDB(String message) {
            // Implementation
        }
    }
    
    class RemoteServiceLog {
        public void logToService(String message) {
            // Implementation
        }
    }
    
    class Logger {
        private InMemoryLog mLog;
        private FileLog fLog;
        private DBLog dbLog;
        private RemoteServiceLog sLog;
        
        public Logger() {
            mLog = new InMemoryLog();
            fLog = new FileLog();
            dbLog = new DBLog();
            sLog = new RemoteServiceLog();
        }
    
        public void log(String message, String loggerMedium) {
            if (loggerMedium.equals("MEMORY")) {
                mLog.logToMemory(message);
            } else if (loggerMedium.equals("FILE")) {
                fLog.logToFile(message);
            } else if (loggerMedium.equals("DB")) {
                dbLog.logToDB(message);
            } else if (loggerMedium.equals("REMOTE_SERVICE")) {
                sLog.logToService(message);
            }
        }
    }

在这个实现中，你已经将单独的代码分离到它们对应的文件中，但是`Logger`类与存储介质的具体实现紧密耦合，如`FileLog`、`DBLog`等。随着存储介质的增加，类中将引入更多的实例`Logger`。

### 还有什么更好的办法吗？ ###

你想了想，上面的实现都是直接写具体的实现类，是面向实现编程，更合理的做法是面向接口编程，接口意味着协议，契约，是一种更加稳定的方式。

1.  定义一个日志操作的接口

public interface LoggingOperation {
        void log(String message);
    }

1.  实现这个接口

class InMemoryLog implements LoggingOperation {
        public void log(String message) {
            // Implementation
        }
    }
    
    class FileLog implements LoggingOperation {
        public void log(String message) {
            //Implementation
        }
    }
    
    class DBLog implements LoggingOperation {
        public void log(String message) {
            // Implementation
        }
    }
    
    class RemoteServiceLog implements LoggingOperation {
        public void log(String message) {
            // Implementation
        }
    }

1.  你定义了一个类，据传递的参数，在运行时动态选择具体实现，这就是所谓的工厂类，不过是基础版。

class LoggerFactory {
        public static LoggingOperation getInstance(String loggerMedium) {
            LoggingOperation op = null;
            switch (loggerMedium) {
                case "MEMORY":
                    op = new InMemoryLog();
                    break;
                case "FILE":
                    op = new FileLog();
                    break;
                case "DB":
                    op = new DBLog();
                    break;
                case "REMOTE_SERVICE":
                    op = new RemoteServiceLog();
                    break;
            }
    
            return op;
        }
    }

1.  现在你的 `Logger`类的实现就是下面这个样子了。

class Logger {
        public void log(String message, String loggerMedium) {
            LoggingOperation instance = LoggerFactory.getInstance(loggerMedium);
            instance.log(message);
        }
    }

这里的代码变得非常统一，创建实际存储实例的责任已经转移到`LoggerFactory`，各个存储类只实现它们如何将消息记录到它们的特定介质，最后该类`Logger`只关心通过`LoggerFactory`将实际的日志记录委托给具体的实现。这样，代码就很松耦合了。你想要添加一个新的存储介质，例如`FLASH_DRIVE`，只需创建一个实现`LoggingOperation`接口的新类并将其注册到`LoggerFactory`中就好了。这就是工厂模式可以帮助您动态选择实现的方式。

### 还能做得更好吗？ ###

你已经完成了一个松耦合的设计，但是想象一下假如有数百个存储介质的场景，所以我们最终会在工厂类`LoggerFactory`中的`switch case`部分`case`数百个。这看起来还是很糟糕，如果管理不当，它有可能成为技术债务，这该怎么办呢？

摆脱不断增长的`if else`或者 `switch case`的一种方法是维护类中所有实现类的列表，`LoggerFactory`代码如下所示：

class LoggerFactory {
        private static final List<LoggingOperation> instances = new ArrayList<>();
    
        static {
            instances.addAll(Arrays.asList(
                    new InMemoryLog(),
                    new FileLog(),
                    new DBLog(),
                    new RemoteServiceLog()
            ));
        }
    
        public static LoggingOperation getInstance(ApplicationContext context, String loggerMedium) {
            for(LoggingOperation op : instances) {
                // 比如判断StrUtil.equals(loggerMedium, op.getType()) op本身添加一个type
            }
    
            return null;
        }
    }

但是请注意，还不够，在所有上述实现中，无论`if else、switch case` 还是上面的做法，都是让存储实现与`LoggerFactory`紧密耦合的。你添加一种实现，就要修改`LoggerFactory`,有什么更好的做法吗？

逆向思维一下，我们是不是让具体的实现主动注册上来呢？通过这种方式，工厂不需要知道系统中有哪些实例可用，而是实例本身会注册并且如果它们在系统中可用，工厂就会为它们提供服务。具体代码如下：

class LoggerFactory {
        private static final Map<String, LoggingOperation> instances = new HashMap<>();
    
        public static void register(String loggerMedium, LoggingOperation instance) {
            if (loggerMedium != null && instance != null) {
                instances.put(loggerMedium, instance);
            }
        }
    
        public static LoggingOperation getInstance(String loggerMedium) {
            if (instances.containsKey(loggerMedium)) {
                return instances.get(loggerMedium);
            }
            return null;
        }
    }

在这里，`LoggerFactory`提供了一个`register`注册的方法，具体的存储实现可以调用该方法注册上来，保存在工厂的`instances`map对象中。

我们来看看具体的存储实现注册的代码如下：

class RemoteServiceLog implements LoggingOperation {
        static {
            LoggerFactory.register("REMOTE", new RemoteServiceLog());
        }
    
        public void log(String message) {
            // Implementation
        }
    }

由于注册应该只发生一次，所以它发生在`static`类加载器加载存储类时的块中。

但是又有一个问题，默认情况下JVM不加载类`RemoteServiceLog`，除非它由应用程序在外部实例化或调用。因此，尽管存储类有注册的代码，但实际上注册并不会发生，因为没有被JVM加载，不会调用static代码块中的代码， 你又犯难了。

你灵机一动，`LoggerFactory`是获取存储实例的入口点，能否在这个类上做点文章，就写下了下面的代码：

class LoggerFactory {
        private static final Map<String, LoggingOperation> instances = new HashMap<>();
    
        static {
            try {
                loadClasses(LoggerFactory.class.getClassLoader(), "com.alvin.storage.impl");
            } catch (Exception e) {
                // log or throw exception.
            }
        }
    
        public static void register(String loggerMedium, LoggingOperation instance) {
            if (loggerMedium != null && instance != null) {
                instances.put(loggerMedium, instance);
            }
        }
    
        public static LoggingOperation getInstance(String loggerMedium) {
            if (instances.containsKey(loggerMedium)) {
                return instances.get(loggerMedium);
            }
            return null;
        }
    
        private static void loadClasses(ClassLoader cl, String packagePath) throws Exception {
    
            String dottedPackage = packagePath.replaceAll("[/]", ".");
    
            URL upackage = cl.getResource(packagePath);
            URLConnection conn = upackage.openConnection();
    
            String rr = IOUtils.toString(conn.getInputStream(), "UTF-8");
    
            if (rr != null) {
                String[] paths = rr.split("\n");
    
                for (String p : paths) {
                    if (p.endsWith(".class")) {
                        Class.forName(dottedPackage + "." + p.substring(0, p.lastIndexOf('.')));
                    }
    
                }
            }
        }
    }

在上面的实现中，你使用了一个名为`loadClasses`的方法，该方法扫描提供的包名称`com.alvin.storage.impl`并将驻留在该目录中的所有类加载到类加载器。以这种方式，当类加载时，它们的`static`块被初始化并且它们将自己注册到`LoggerFactory`中。

### 如何在 SpringBoot 中实现此技术？ ###

你突然发现你的应用是springboot应用，突然想到有更方便的解决方案。

因为你的存储实现类都被标记上注解`@Component`，这样 `Spring` 会在应用程序启动时自动加载类，它们会自行注册，在这种情况下你不需要使用`loadClasses`功能，`Spring` 会负责加载类。具体的代码实现如下：

class LoggerFactory {
        private static final Map<String, Class<? extends LoggingOperation>> instances = new HashMap<>();
    
        public static void register(String loggerMedium, Class<? extends LoggingOperation> instance) {
            if (loggerMedium != null && instance != null) {
                instances.put(loggerMedium, instance);
            }
        }
    
        public static LoggingOperation getInstance(ApplicationContext context, String loggerMedium) {
            if (instances.containsKey(loggerMedium)) {
                return context.getBean(instances.get(loggerMedium));
            }
            return null;
        }
    }

`getInstance`需要传入`ApplicationContext`对象，这样就可以根据类型获取具体的实现了。

修改所有存储实现类，如下所示：

import org.springframework.stereotype.Component;
    
    @Component
    class RemoteServiceLog implements LoggingOperation {
        static {
            LoggerFactory.register("REMOTE", RemoteServiceLog.class);
        }
    
        public void log(String message) {
            // Implementation
        }
    }

### 总结 ###

我们通过一个例子，不断迭代带大家理解了工厂模式，工厂模式是一种创建型设计模式，用于创建同一类型的不同实现对象。我们来总结下这种动态选择对象工厂模式的优缺点。

**优点：**

*  容易管理。在添加新的存储类时，只需将该类放入特定包中，在static代码块中注册它自己到工厂中。
 *  松耦合，当您添加新的存储实现时，您不需要在工厂类中进行任何更改。
 *  遵循SOLID编程原则。

**缺点：**

*  如果是用原生通过类加载的方式，代价比较大，因为它涉及 I/O 操作。但是如果使用的是SpringBoot，则无需担心，因为框架本身会调用组件。
 *  需要额外编写一个`static`块，注册自己到工厂中，一不小心就遗漏了。