如何设计代码逻辑

不知道你是否有这样的困惑，在做业务逻辑的开发中，通常会有这些情况：

围绕一些数据的增删改查
原始的获取方法可能是耗时的，异步的，产品上要求需要快速获取到，因此引入缓存
多个业务逻辑存在交叉
最后各种类、各种数据混杂在一起，难以区分，难以找到，难以管理

这里我做了一点思考，总结出一些经验，记录一下。

先构思一下哪些是核心的对象实体，需要操作的东西到底是什么？

举个例子，比如要做一个相册管理，那么核心的实体，应该是【相册】和【照片】。应该会有很多方法围绕着如何获取相册，如何获取照片，如何保存照片，修改照片来展开。

因此我们这里要抽象的代码为：

kotlin 复制代码

class Album {

}

class Photo {

}

我之前犯的一个错误是，喜欢使用 Manager 这样的概念来做代码。比如，我现在认为不太好的一个想法是：哦，管理的是相册和照片，那么就搞一个【相册照片管理器】，里面提供一堆接口来实现这样的功能。于是 PhotoManager 就诞生了。然后就在里面不断的增加代码和方法，越来越庞大，最后难以抽离。

有了核心实体后，我们来考虑一下内部的方法应该如何设计。

设计内部的方法

设计方法的时候，应该从使用者的角度来考虑，需要考虑两个方面：

使用者怎么使用方便
使用者应该能猜测到大概是什么方法

比如相册里面应该提供获取照片的方法吧，如果我是使用者，那么我第一反应是 getPhotos() 这样的名字。

swift 复制代码

class Album {
    func getPhotos() -> Array<Photo>
}

如果是耗时的，加上缓存

如果获取照片的内部实现是耗时的，或者是异步的，那么就只能通过callback的方法返回（还有一种 async await 的方式），自然的实现就会变成下面的样子。

如果需要缓存获取，可以将缓存以返回值的形式返回，最新的结果以callback的形式返回。

swift 复制代码

class Album {
    func getPhotos(callback: (Array<Photo>)->Void) -> Array<Photo>
}

缓存对象先各自为战，如果有必要，再使用单例进行统一管理

想象一下，如果最初使用的是 PhotoManager 来进行照片管理，如果照片也需要缓存，相册也需要缓存，那么很可能，PhotoManager 里面就有很多个成员变量用来记录缓存数据，久而久之，它们会随着你对它们的记忆程度的衰退而不断陈旧，渐渐的搞不清怎么回事。

我想到的一种比较好的方式就是就近处理，如果是有交叉的关系，那么可以再单独搞一个类来处理，总之就是将于某个实体有关的，都约束在这个实体内部。