设计模式-外观模式

外观模式

画皮画虎难画骨，知人知面不知心

相同的外观下，蕴含丰富的内涵，甚至迥异的操作，这就是外观模式。

---

前面我们实现的几种模式，常说的有一点，保证外部API的单调性。

外观模式就是这样的东西，或者换一种说法：面向接口编程。

当我专注于流程和组织的时候，使用接口构建出纯粹的抽象业务，此时，我可以说我的工作完成了。

因为业务流程的确如此，但是涉及到不同的细节场景，每种的具体处理有时候天差地别。

让每个业务线的人员自行去进行填充实现就好了。

---

著名的slf4j，本身就是个空壳子，如果不引入具体实现的包，真的用不了。

keras也是，虽然被冠以框架之名，但是更多的精力是定义了各种框架的接口标准，底层具体实现还是需要对接其他框架。

不得不说，对于非关注点，我们的确只需要一个统一的简单的方式交互，能使用就行。

这样就能够更快的解决问题，去开发产品。

---

必定需要这么一个东西，去能够包容差异，又能够统一交互，这就是外观模式。

现在可以稍微修饰一下前面的叙述，丰富的内涵是必须的，但是不应该迥异。

实现一下

接口

public interface LoggerInterface {
    void log(String msg);
}

工厂

@Component
public class LoggerFactory {
    static LoggerInterface loggerInterface;
    public static LoggerInterface getLogger(Class<? extends  Object> clazz){
        return (msg)->{
            loggerInterface.log(String.format("%s : %s", clazz.getName(), msg));
        };
    }
    @Autowired
    public void setLoggerInterface(LoggerInterface loggerInterface) {
        LoggerFactory.loggerInterface = loggerInterface;
    }
}

实现

@Component
public class ErrorLogger implements LoggerInterface {
    @Override
    public void log(String msg) {
        System.err.println(msg);
    }
}

使用

public class Entrance {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Config.class);
        LoggerFactory.getLogger(Entrance.class).log("fuck");
    }
}

你可以换打印方法，甚至直接输入到数据库，redis，mysql都随意，但是我的最外面的调用方式是不变的。

这里也凸显了外观模式的另一个极大的作用，那就是在不用修改代码的情况下完成逻辑更新。

小结

设计模式之间并没有明确的界限，之间的区别都只是在各自领域内的差异，甚至于微小而不可见。

• 工厂模式

相同方式，多个对象

• 策略模式

相同方式，多种处理

• 外观模式

相同方式，多种实现

---

诸多设计模式看起来都有巧立名目之嫌，但是核心思想总是不变的。

模板方法也是一样的套路，嗯，慢慢遍历吧。