1、故事背景:
之前公司用的是阿里云的oss,后面需要做私有化部署,所以增加了s3。但是项目只有一个,这就意味着我要根据配置选择当前项目使用oss还是s3,这时候就想到了策略模式不就是根据不同的环境选择不同的算法吗。
2、简单介绍一下策略模式(来源菜鸟):
意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决:在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护。
何时使用:一个系统有许多许多类,而区分它们的只是他们直接的行为。
如何解决:将这些算法封装成一个一个的类,任意地替换。关键代码:实现同一个接口。
应用实例: 1、诸葛亮的锦囊妙计,每一个锦囊就是一个策略。 2、旅行的出游方式,选择骑自行车、坐汽车,每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。
优点: 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点: 1、策略类会增多。 2、所有策略类都需要对外暴露。使用场景: 1、如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为,如果不用恰当的模式,这些行为就只好使用多重的条件选择语句来实现。
3、之前是结构是什么样的
之前公司就是在common里面有一个OSSUntils工具类跟一个OSSService暴露给外面使用,这次增加了S3之后就肯定要对之前的接口进行改造
4、对之前的接口进行改造
4.1 增加抽象接口
public interface FileStrategyService {
}
4.2 增加S3Service 改造OSSService implements FileStrategyService
这里就不贴具体的代码实现了,有一点需要注意的是Service上面不能加任何bean的注入,具体原因后面再说
public class OssFileService implements FileStrategyService{
}
public class S3FileService implements FileStrategyService{
}
4.3 增加文件配置
@Configuration
public class FileConfig {
@Bean("oss")
@ConditionalOnProperty(value = "file.strategy", havingValue = "oss")
FileStrategyService ossFileStrategyService() {
return new OssFileService();
}
@Bean("s3")
@ConditionalOnProperty(value = "file.strategy", havingValue = "s3")
FileStrategyService s3FileStrategyService() {
return new S3FileService();
}
这里就是通过配置文件读取到的 file.strategy 的值进行判断
如果为oss的话就注入OSSService,如果为S3就注入S3Service。这样我们在使用的时候,直接使用FilestrategyService就行了,具体的实现类由配置控制,上面service不让注入的原因就是在这里进行了@Bean的注入,如果上面进行了@Service注入就会在使用FileStrategyService时出现找不到具体实现类的情况。
4.4 使用场景
private String generateSlideAssetDownloadUrl()
return fileStrategyService.getCSDownloadUrlSpecFileName(downloadUrl, null, fileName);
}