深入理解 Android 架构 Clean Architecture(补充篇)

深入理解 Android 架构 Clean Architecture(补充篇)_第1张图片
在前两篇的介绍篇和解析篇中,我们已经对 Clean Architecture 的核心思想和层次结构进行了初步了解。然而,我发现遗漏了部分知识点,本篇将逐一讲解补充,最后介绍项目实践。

架构图的提炼

在介绍篇中提到的关于 Clean Architecture 图解,其实每一层中都包含了一些我们不需要的东西,因为该架构是一个通用的架构思想,所以在去除掉一些无关的内容后
示例图如下:
深入理解 Android 架构 Clean Architecture(补充篇)_第2张图片

数据层中的模型(Model)

数据层不仅由 Repository、DataSource组成,还包含数据模型(Models)。其中模型(Models)扮演着重要的角色。模型是数据层的组成部分,负责表示和处理应用程序中的数据。

Models 定义了应用程序中的数据结构,包括实体的属性、关系等。这可以是网络请求的数据格式、数据库表的映射。

在接口适配器层和用例层之间(绿色与红色),模型可能需要进行数据转换,以适应不同层次之间的需求。这可以包括将数据库实体映射为用例需要的 Domain Model(领域实体)等。

示例:

//网络模型
data class User(
  val name:String,
  val age:Int,
  val gender:Int
  ...
)

//数据库模型
@Entity
data class Note(
  val title:String,
  val content:String,
  val timestamp:Long
  ...
)

SOLID原则

SOLID 也是 Uncle Bob 提出的一组设计原则,旨在帮助开发者创建可维护、灵活且易于理解的软件架构,在Clean Architecture 架构中也遵循了这一原则。

  • 单一职责原则:一个类应该只有一个引起变化的原因。这意味着一个类应该只负责一种类型的任务,它应该只有一个责任。
  • 开闭原则:软件实体(类、模块、函数等)应该对扩展是开放的,但对修改是封闭的。这意味着可以通过添加新功能来扩展系统,而无需修改现有代码。
  • 里氏替换原则:子类型必须能够替换掉它们的父类型,而不影响程序的正确性。
  • 接口隔离原则:不应该强迫一个类实现它用不到的接口。应该为客户端提供他们需要的接口,而不强迫他们依赖他们不需要的接口。
  • 依赖反转原则:高层次的模块不应该依赖于低层次的模块,二者都应该依赖于抽象。抽象不应该依赖于具体实现,而具体实现应该依赖于抽象。

总结

Clean Architecture 提供了一种强大的软件设计理念,其核心思想是通过分层和分离关注点的方式构建可维护、可测试和可扩展的软件系统。将系统分为实体、用例、接口适配器和框架与驱动器四个层次,每个层次有着清晰的责任和依赖规则。这样的结构确保了业务逻辑的纯粹性,使得系统内核独立于外部细节。同时,Clean Architecture 强调了 SOLID 原则的应用,进一步提升了代码的灵活性和可维护性。

这里推荐一个示例项目 SocialNetworkApp,该项目应用了干净架构并使用 Jetpack Compose + MVI实现,通过该示例可以更好的学习干净架构在 Android 中的应用以及每一层的职责体现,欢迎 Star !

源码地址:https://github.com/AAnthonyyyy/SocialNetworkApp


最后,可以关注一下本人的公众号,会不定期发布一些关于 Android、Kotlin、Jetpack Compose相关的学习笔记和知识。

深入理解 Android 架构 Clean Architecture(补充篇)_第3张图片

你可能感兴趣的:(Clean,Architecture,架构,android,kotlin,android-studio,android,jetpack)