阿里P8架构师都是怎么分析软件模型的?

x33g5p2x  于9个月前 转载在 其他  
字(2.6k)|赞(0)|评价(0)|浏览(63)

面对一个新项目,如何理解它的模型呢?

要先知道项目提供了哪些模型,模型又提供了怎样的能力。若只知道这些,你只是在了解别人设计的结果,这不足以支撑你后期对模型的维护。

在一个项目中,常常会出现新人随意向模型中添加内容,修改实现,让模型变得难以维护。原因在于对模型的理解不够

模型都是为解决问题,理解一个模型,需要了解在没有这个模型之前,问题是如何被解决的?
这样,你才能知道新的模型究竟提供了怎样的提升,这是理解一个模型的关键。

本文以Spring的IoC容器为例,来看看怎样理解软件的模型。

耦合的依赖

Spring的根基就是IoC容器,即“ 控制反转”,也叫依赖注入。
IoC容器是为了解决什么问题呢?

组件创建和组装问题。

为什么这是个亟待解决的问题?

软件设计需要有个分解过程,必然还面对一个组装过程,即将分解出的各组件组装到一起完成功能。

案例

某博客服务提供:根据标题查询博客。

ArticleService处理业务过程中,需用ArticleRepository辅助完成功能,即ArticleService依赖ArticleRepository。
这时你会怎么做?

直男做法,在 ArticleService新增一个ArticleRepository字段:

看起来好像还行。
那这个字段怎么初始化?

直男反应:直接new!

看起好还能用,但实际上DBArticleRepository不能这样初始化。
就如实现类的名字,这里要用到DB。但在真实的项目中,由于资源所限,一般不会在应用中任意打开DB连接,而是会共享DB连接。
所以,DBArticleRepository需要一个DB连接(Connection)参数。

于是你决定通过构造器把这个参数传入:


看上去也还正常。既然开发完了,那么开始测试吧:
要让ArticleService跑起来,就得让ArticleRepository也跑起来;就得准备好DB连接。

是不是太麻烦,想放弃测试了?。但你还是决定坚持一下,去准备DB连接信息。

然后,真正开始写测试时,发现,要测试,还要在DB里准备数据:

  • 测查询,得事先插入一些数据吧,看查出来的结果和插入的数据是否一致
  • 测更新,得先插入数据,测试跑完,再看数据更新是否正确

咬咬牙准备了一堆数据,你开始困惑了:我在干什么?我不是要测试服务吗?做数据准备不是测试仓库的时候该做的事吗?
所以,你发现问题在哪了吗?

在你创建对象的那刻,问题就出现了。

分离的依赖

当我们创建一个对象时,就必须要有个实现类,即DBArticleRepository。
虽然ArticleService写得很干净,其他部分根本不依赖DBArticleRepository,只在构造器里依赖,但依赖就是依赖。

而且由于要构造DBArticleRepository,还引入了Connection类,该类只与DBArticleRepository的构造有关系,与ArticleService业务逻辑毫无关系。

只是因为引入一个具体实现,就需要把它周边全部东西引入,而这一切都与业务类本身的业务逻辑没一毛钱关系。
这就像是,你原本打算买套房子,现在却让你必须了解怎么和水泥、砌墙、怎么装修、户型怎么设计、各个家具怎么组装,而你想要的只是一套能住的婚房。

实际项目,构建一个对象可能牵扯更多内容:

  • 根据不同的参数,创建不同的实现类对象,你可能需要用到工厂模式
  • 为了解方法执行时间,需要给被依赖的对象加上监控
  • 依赖的对象来自于某个框架,你自己都不知道具体的实现类咋样的
    ……

即便是最简单的对象创建和组装,看起来也不是多简单。

直接构造存在这么多问题,最简单的就是把创建的过程拿出去,只留下与字段关联的过程:

这时的ArticleService就只依赖ArticleRepository。
测试ArticleService也很简单,只要用一个对象模拟ArticleRepository的行为。通常这种模拟对象行为的工作用一个现成的程序库就可以完成,就是那些Mock框架。

之前的代码里,如果我用Mock框架模拟Connection类是不是也可以?
理论上,是可以。但是想要让ArticleService的测试通过,就必须打开DBArticleRepository的实现,只有配合着其中的实现,才可能让ArticleService跑起来。显然,你跑偏了。

对象的创建已经分离了出去,但还是要要有一个地方完成这个工作,最简单的解决方案自然是,把所有的对象创建和组装在一个地方完成:

相比业务逻辑,组装过程很简单,仅仅是个对象创建及传参。
最好的解决方案就是有个框架。Java的这种组装一堆对象的东西一般被称为“容器”。

至此,一个容器就此诞生。它解决的是依赖问题,把被依赖的对象注入到目标对象,所以叫“依赖注入”(Dependency Injection,简称 DI)。这个容器就叫DI容器。

这种创建和组装对象的方式在当年引发了很大的讨论,直到最后Martin Fowler写了一篇《反转控制容器和依赖注入模式》,才算把大家的讨论做了一个总结,行业里总算达成共识。
说了这么多,和我们要讨论的“模型”有什么关系?

很多人习惯性把对象的创建和组装写到了一个类里,导致代码出现大量耦合。
也导致项目很难测试,可测试性是衡量设计优劣的一个重要标准。

有了IoC容器后,你的代码就只剩下关联的代码,对象的创建和组装都由IoC容器完成。不经意间,还做到了面向接口编程,实现是可以替换的,且可测试。
容器概念还能继续增强。比如,我们想给所有与数据库相关的代码加上时间监控,只要在容器构造对象时添加处理即可。这就是 AOP,而这些改动,对业务代码透明。
但还是很多程序员即便用Spring,依然是自己构造对象,静态方法随便写。

总结

理解模型,要知道项目提供了哪些模型,这些模型都提供了怎样的能力。
更重要的是了解模型设计的渊源:

  • 可增进对它的了解
  • 也会减少我们对模型的破坏或滥用

IoC容器有效地解决了对象的创建和组装的问题,让程序员们拥有了一个新的编程模型。

按照这个编程模型去写代码,整体的质量会得到大幅度的提升,也会规避掉之前的许多问题。这也是一个好的模型对项目起到的促进作用。像DI这种设计得非常好的模型,你甚至不觉得自己在用一个特定的模型在编程。

理解模型,要了解模型设计的来龙去脉。

相关文章