关于思考题我想出两种方法改进：简单工厂方法和使用反射。

1、简单工厂方法
ImageStore imageStore = ImageStoreFactory.newInstance(SOTRE_TYPE_CONFIG);
config文件可以写类似properties的文件，使用key-value存储。

缺点：再新增另一种存储手段时，需要修改工厂类和添加新的类。修改工厂类，违反了开放-封闭原则。

那有没有更好一点的方法呢？

2、使用反射。
在配置文件中定义需要的image store类型。
在ProcessJob中
ImageStore store = (ImageStore) Class.forName(STORE_CLASS)
    .newInstance();

缺点：使用反射，在大量创建对象时会有性能损失。

关于减少ProcessJob中的修改，还有没有更好的方法呢？我只是抛砖引玉，希望和大家一起讨论。具体实现：https://github.com/gdhucoder/Algorithms4/tree/master/geekbang/designpattern/u009

补充：
关于access token：Aliyun的AccessToken时有expireTime时限的。不需要每次重新获取，过期时重新获取即可。

课堂讨论answer:
考虑使用工厂模式生成ImageStore实例.这样就可以将调用者和具体ImageStore解耦.

例:
public class ImgStoreFactory {

    private ImgStoreFactory(){

    }

    public static ImageStore create(Class<?> clz){
        if (clz == AliyunStore.class){
            return new AliyunStore();
        }else if (clz == PrivateYunStore.class){
            return new PrivateYunStore();
        }else {
            throw new IllegalStateException("..");
        }
    }

    public static void main(String[] args) {
        ImageStore store = ImgStoreFactory.create(AliyunStore.class);
        store.dosth();
    }
}

另外有一点不太同意作者的说法:
上节课作者将Contract翻译为"协议",
我认为是不恰当的.
在计算机领域, 通常使用Protocol代表协议.
个人认为Contract更恰当的翻译是"契约".

要不是有一开始的课程大纲，我以为课堂讨论是要启发大家，在下节就要讲创建型模式，工厂模式，工厂方法什么的了

但转念一想，这想法或许太肤浅了，毕竟大多数创建型方法都有一个明显的对具体类型的依赖（这里先预先排除抽象工厂，觉得有点小题大做这样搞），都不是一个最终能让人感到内心宁静的做法

这节既然讲的是依赖于抽象而不是依赖于具体，那比较得瑟的玩儿法恐怕应该是直接在ImageProcessingJob类和ImageStore接口这两个类型关系上充分体现出依赖倒置的思路，把最后一点执行创建ImageStore类型实例的痕迹彻底关在ImageProcessingJob的门外，虽然必然得有人去考虑实际至少调一下ImageStore具体类型实例的这个创建过程，但ImageProcessingJob这爷是不打算操心这事了，它只需要留个口子，让别人把ImageProcessingJob放到自己锅里，自己就可以开始炒菜了

也就是从形式上，ImageProcessingJob这个类只需要保留对ImageStore接口的依赖就可以了，具体留口子的手段则要考虑依赖注入，形式上有两种：

+ 一种是可能更OO样子的一点，即声明一个ImageStore的field在ImageProcessingJob类里面
  - 如果说有什么好处，恩，可以理解为能对客户程序隐藏了ImageStore类型的信息，是的，连类型信息都隐藏掉；好吧，还是得关心别人，毕竟这世界上不是仅有自己一个
  - 具体操作起来，由于不能声明field时候直接new，要不又变回去了，但又不能NPE吧，所以不考虑创建，我还是得考虑怎么把实例请进来，就是上面说的至少留个口子
  - 这时候可能不得不借助依赖注入的帮助了（否则就是依赖查找，还是工厂），即
  - 通过ImageProcessingJob的构造函数注入或者利用field注入来获取ImageStore接口的实例，或者ImageProcessingJob如果依赖项多，Builder一下也很好
  - 毕竟ImageProcessingJob这个类型在我们讨论的上下文里面是如此具体的一个类，就不过分追溯它的创建责任及执行在哪里了
+ 另一种，表面粗暴直接看似问题多多，但是细品也有点意思的，那就是process方法直接增加一个ImageStore的参数就完了，OMG我在干什么
  - 没有B方案的设计自身无法证明自己更好
  - 相对于上面的，直接的问题是会对process方法直接依赖的客户程序会和ImageStore这个类型产生耦合
    * 如果客户程序是一个类（还能是什么？），要么有一个field等着inject进来，要么是通过调用process的method传进来，要么就是无中生有（直接new了或用创建型模式）
    * 这都可能造成没有充分的设计隔离，至少让客户程序造成信息冗余，承担了不必要的职责等问题
  - 但事实上也不是完全没好处，这种灵活性体现在它没有把ImageStore的逻辑固化在任一个ImageProcessingJob实例里面
    * 考虑上面第三类无中生有的方式，假设是创建型的工厂方法或类似手段，则可以提供对method参数（业务层面的动态输入，例如最终操作用户的提供的值）的响应能力
    * 这和，执行排序算法骨架确定，但是需要给定两个元素（复杂对象）比较规则这种思路有相似之处，毕竟我需要的是对方的能力而不是对方的数据或者数据视图，这时候这么做还是很有诱惑力的
  - 如果脱离开场景，实际上这种动态性还更强，但问题就在于这种动态性会不会对于具体场景有价值
  - 从这个实例上看，也许没这么明显，因为不同的对象存储后端更有可能是环境（测试、生产？但12 factor让我们...好歹测试环境还是也上云吧）不同造成的，而非基于动态的用户信息输入
  - 但，事无绝对吧，假设，用户有选择我要针对具体这一张，我特么上传那一刻选择一个存储后端的需求
    - 然后为了方便用户，用户竟然可以勾选，以后使用同样地选择...
    - 我觉得除了脑子进水的犬类应该没人会干这种没问题制造问题也要上的方案吧
 
 所以综上所属，还是field一个ImageStore接口来搞吧

这极客时间也让人想吐槽，能敲2000字，结果就只留这么大点儿一个输入框...你要不就限制200字我还能少敲一点...我这写的兴起还得外面写完了贴过来...

关于什么时候定义接口的一些拙见：
当方法会有其他实现，或者不稳定的时候需要定义接口；
1.不稳定的方法一般能事先确定，用接口能提高可维护性
2.但在开发时往往不确定是否需要其他实现，我的原则是等到需要使用接口的时候再去实现。所以根据kiss原则一般我会先用方法实现，如果有一天真的需要有新的实现的时候再重新抽象出接口对代码进行小重构。

就老师的例子进行一下说明：
刚开始只需要阿里云进行图片上传下载功能，我就先只实现阿里云的图片上传下载方法。
后期发现需要有私有云的上传下载方法的话，那就对这个功能通过接口进行抽象。但是你永远不知道到底是新的图片上传下载功能先来到还是其他阿里接口先来到，如果是新的阿里接口，也是用的这一套token方法，那就用抽象方法或接口对token部分实现抽象。

课后问题：
简单工厂，工厂模式可以提高可扩展性，维护性。
java spring项目可以使用注入的方式。