Too many if-else item backgrounds
If you know the current business needs from the beginning, most people will not add too many if-else judgments in the code. The bad code is basically that there is not much demand when the code is first written. With constant revisions and increases, the development time is relatively tight, and the code is often written as fast as possible. Of course, writing one more if-else is definitely faster than using various design patterns, which is the main reason why the project code gradually becomes bloated and difficult to maintain. When you have free time, you can perform an operation on the previous code.
First look at the code before this optimization:
@Override
public MMediaInfo copyToLibType(UserQiniuDTO userQiniuDTO, Long mediaId, Integer libType) {
MMediaInfo mMediaInfo = new MMediaInfo();
LibTypeEnum libTypeEnum = LibTypeEnum.valueof(libType);
if (libTypeEnum.getFileType().equals(FileType.VIDEO)) {
mMediaInfo = mvideoInfoService.copyToLibType(userQiniuDTO, mediaId, libType);
}
if (libTypeEnum.getFileType().equals(FileType.AUDIO)) {
mMediaInfo = mAudioInfoService.copyToLibType(userQiniuDTO, mediaId, libType);
}
if (libTypeEnum.getFileType().equals(FileType.PICTURE)) {
mMediaInfo = mImgInfoService.copyToLibType(userQiniuDTO, mediaId, libType);
}
if (libTypeEnum.getFileType().equals(FileType.FILE)) {
mMediaInfo= mFileInfoService.copyToLibType(userQiniuDTO, mediaId, libType);
}
return mMediaInfo;
}
There will be some pieces of code, the main reason is that in the early stage of the project, there are only video/audio requirements, and the audio operation interface, the logic is separated, and the picture/file requirements are added later, and the video/audio/file/picture is required Can be merged and processed in the same interface, which leads to a lot of if-else judgments in many operations in the code.
Look at the optimized code:
@Override
public MMediaInfo copyToLibType(UserQiniuDTO userQiniuDTO, Long mediaId, Integer libType) {
LibTypeEnum libTypeEnum = LibTypeEnum.valueof(libType);
IFileService iFileService = FileFactory.getFileService(libTypeEnum.getFileType());
return iFileService.copyToLibType(userQiniuDTO, mediaId, libType);
}
This broken code looks much cleaner. The basic idea of the implementation is to use the strategy mode + factory mode. The code returns the corresponding implementation class through different file types to realize the copy logic.
Basic Video Steps
- Create the IFileService interface
public interface IFileService {
Integer getFileType();
MMediaInfo copyToLibType(UserQiniuDTO userQiniuDTO, Long mediaId, Integer libType);
}
- Video/audio/picture/file class video IFileService interface respectively
public class MVideoInfoServiceImpl extends ServiceImpl<MvideoInfoMapper, MvideoInfo> implements MvideoInfoService, IFileService {
@Override
public Integer getFileType() {
return FileType.VIDEO;
}
@Override
public MMediaInfo copyToLibType(UserQiniuDTO userQiniuDTO, Long id, Integer libType) {
//复制视频逻辑
return mMediaInfo;
}
- Create a FileFactory factory class
@Component
public class FileFactory implements ApplicationContextAware {
private static Map<Integer, IFileService> fileServiceMap;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
Map<String, IFileService> map = applicationContext.getBeansOfType(IFileService.class);
fileServiceMap = new HashMap<>();
map.forEach((key, value) -> fileServiceMap.put(value.getFileType(), value));
}
public static <T extends IFileService> T getFileService(Integer fileType) {
return (T)fileServiceMap.get(fileType);
}
}
Summarize
copyToLibType is just a way of optimization, and there are many codes in IFileService such as moving/deleting, which can also kill too many if-else.