
4.4
数据结构为王
|
107
因此,应该让处理某个特定数据结构的代码包含在尽可能少的模块中。比如,
假设我们有一个
BlogPost
数据库模型,一开始将所有关于
BlogPost
的逻辑
都放到一个文件中是合情合理的。在那个文件中,我们可以暴露一个
API
供使用者创建、部署、编辑、删除、更新、搜索或者分享博客文章。随着
相关的功能越来越丰富,我们可以选择将逻辑分散到几个位于相同位置的
文件中 :其中一个文件可能处理搜索,解析原始的终端用户的查询标签和
术语,然后将其传递给
Elasticsearch
或者其他搜索引擎 ;另一个文件可能
处理分享,暴露一个
API
,用于以邮件的形式或者通过其他社交平台分享
文件,以此类推。
将逻辑拆分到同一个目录下的多个文件中,有助于防止功能“爆炸”,这些
功能很大程度上只有数据结构是相同的,可以将其与功能紧密相关的代码
放在一起。
还有一个方案是,将应用程序某个特定方面的相关逻辑(如博客文章)直
接放到需要这个逻辑的组件中,但是在未加控制的情况下会造成麻烦。这
样做可能于短期生产力有益,但从长远来看,我们需要担心将逻辑(在这
个例子中是与博客文章严格相关的逻辑)与完全不同的关注点耦合的问题。
同时,如果我们将大量逻辑分散到不相关的组件中,在对代码进行大规模
更新时,可能有遗漏功能的关键部分的风险。最终我们可能会做出错误的
假设,或者犯下在未来的某个时间点才可能变得明显的错误。
当不清楚功能是否会增加或者会如何增加时,一开始将逻辑直接放到需要
它的地方是可以接受的。一旦初期探索阶段结束,并且知道该功能会继续 ...