iOS三级缓存库的实现心得

前段时间因为工作需要就自己写了一个iOS的三级缓存库主要用来缓存文本（缓存到数据库中）和图片（缓存到自己指定的本地目录下）。

注：其实利用现有的第三方库（比如：SDWebImage， EGOImage）可以完成我们的大部分功能，但这里有一些定制化的功能，比如不同模块的图片要缓存在不同的目录中，以便于以后查找和清理，所以就选择了自己来封装一个。

在写这个库时，学到了很多封装东西时的思想，比如先要明确需求是什么，在明确需求后，接下来要定义实现需求所需要的接口，然后再根据定义的上层接口来定义完成上层接口功能所需要的底层接口，这样一层层的深入逐渐细化功能，直到接口功能不可再分，接下来从最底层接口的功能，紧接着其上层接口调用底层接口来完成上层接口的功能，这样一层层的向上回溯，直到实现最上层定义的接口的功能。用这种方式写一个很复杂的库时，可以将一个很复杂的功能，逐步分解很多相对容易实现的小功能，同时从接口的调用关系上可以很容易的看出功能逻辑实现的过程。这样既使得功能的逻辑变得清晰（易于理解），也将一些独立的功能模块分离开来，避免使整个复杂的功能逻辑都写在一起（这样会使得逻辑看上起非常复杂而难以理解），实现了独立功能之间的解耦。

下面简单介绍下这个库实现的过程。按照上面的分析过程，首先我们的需求是：要缓存文本和图片 ，同时还要定期清理一些已经不用的本地图片（这里采取的策略是每次启动应用程序检查无用的图片然后清理）。其中文本要缓存到数据库中，图片要缓存到特定的本地目录下（有时是库本身写死的一个本地目录，有时是客户端指定的本地目录，当然可设置一个默认的缓存目录，当客户端未指定目录时，就缓存在默认的缓存目录下）。

明确了需求就可以思考如何设计接口来实现我们的需求了。首先我们定义一个最上层的供客户端直接使用的类，可命名为CacheManager。CacheManager类中定义了客户端所要调用的关于文本与图片所有操作的接口。

首先讨论文本部分。我们项目中预置了一个包含很多属于同一数据结构但数据内容不同的模型的文本的text文件。我们的思路是程序启动时首先检查数据库中是否有这一结构的表，如果有就从数据库中读取，然后显示在界面上。如果没有就从我们预置的text文件中读取该结构的数据，然后显示在界面上（测了一下该过程不会耗费太多时间，就将从检查到显示的整个过程都放在了主线程中进行，因为检查数据与显示数据不是在同一个界面进行，这样做也是为了数据的同步）。下面来定义相应接口，(时间关系，未完待续)