show me your code
思考
在开始源码实现前,先思考个问题:代码的设计怎样才是好的?
经常会有新人问:
1.为什么不写在一起,调用方便,还要拆分出来?
2.为什么说这个方法只调用了一次没必要拆分出来?
3.为什么说我这个拆分不合理,反而复杂化了?
...
这个代码设计有很多原则是要遵循的,但是仁者见仁智者见智,很难有统一的标准,所以没有最好的,只有目前个人认为最合适。在此,仅通过此例子分享下~~ :)
拆分
//file管理者,通过此类可进行文件管理
YHFileManager.h
//解压缩文件 执行者
YHFileCompress.h
//其余文件操作 执行者,对系统api的封装简化使用
YHFileAction.h
这样设计的原因?个人思考:
1.我想让使用者无需关心底层实现,只通过上层来直接使用,同时为避免过多类引起记忆麻烦,所以提供了一个文件管理类入口,通过这个类即可完成文件相关操作。
2.解压缩文件,使用的第三方实现的,所以依赖于第三方,在此单独拿出来对第三方进行了封装,再使用。
3.对系统提供的API进行封装,简化操作。
在fileManager内实际使用了也是其余两个类。那么这样封装的益处:
1.有统一入口对文件进行操作
2.依赖于第三方实现的解压缩文件,即时更换第三方,也不影响用户基于fileManager写的文件相关操作,因为上层是不动的,底层的更换变迁不影响对外使用。
3.对系统提供的文件相关操作的API的封装,暴漏外部接口给fileManager使用,而不暴漏具体实现,这样一来,无论底层怎样变动,我都不用修改fileManager,而只需修改很少的代码,因为修改涉及的代码越多,不确定性和危险性越高,尽量尽可能小的改动来完成代码的升级和维护。
所以,我基于以上原因,就拆分成三个类了相信有大牛和大神会有更加好的方案我就抛石子引板砖了
任何优秀的代码都是一点点改进出来的,只有不断琢磨和思考,推敲,才能逐渐迭代出优秀结构的轮子所以,从眼前一小步一小步开始,不断推敲优化自身代码,不断进步
源码也没有什么可讲解的,直接拿来用吧
看~灰机~灰机灰过去了~灰机又灰过来了