如何设计代码逻辑

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

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

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

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

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

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

kotlin 复制代码
class Album {

}

class Photo {

}

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

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

设计内部的方法

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

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

比如相册里面应该提供获取照片的方法吧,如果我是使用者,那么我第一反应是 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 里面就有很多个成员变量用来记录缓存数据,久而久之,它们会随着你对它们的记忆程度的衰退而不断陈旧,渐渐的搞不清怎么回事。

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

相关推荐
西陵1 小时前
Nx带来极致的前端开发体验——借助playground开发提效
前端·javascript·架构
Edingbrugh.南空1 小时前
Aerospike架构深度解析:打造web级分布式应用的理想数据库
数据库·架构
人生都在赌2 小时前
从拒绝Copilot到拥抱GPT-5 Agent:一个Team Leader的效能革命
人工智能·架构·devops
沐森2 小时前
今日谈:electron集成appex
架构
小裕哥略帅2 小时前
架构师--基于常见组件的微服务场景实战
微服务·云原生·架构
苦逼前端画 K 线5 小时前
期货交易系统界面的技术架构与功能实现解析
架构·期货配资软件·大宗交易软件·子母账户系统·文华财经·倚天
DemonAvenger5 小时前
HTTP/2在Go中的实现与优化
网络协议·架构·go
范纹杉想快点毕业19 小时前
ZYNQ芯片,SPI驱动开发自学全解析个人笔记【FPGA】【赛灵思
stm32·单片机·嵌入式硬件·mcu·架构·51单片机·proteus
Pomelo_刘金20 小时前
Worker 常用 6 种结构与适用场景
架构
亿道电子Emdoor20 小时前
【ARM】ARM架构基础知识
arm开发·架构·arm