在前两篇的介绍篇和解析篇中,我们已经对 Clean Architecture 的核心思想和层次结构进行了初步了解。然而,我发现遗漏了部分知识点,本篇将逐一讲解补充,最后介绍项目实践。
架构图的提炼
在介绍篇中提到的关于 Clean Architecture 图解,其实每一层中都包含了一些我们不需要的东西,因为该架构是一个通用的架构思想,所以在去除掉一些无关的内容后
示例图如下:
数据层中的模型(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文章来源:https://www.toymoban.com/news/detail-778847.html
最后,可以关注一下本人的公众号,会不定期发布一些关于 Android、Kotlin、Jetpack Compose相关的学习笔记和知识。
文章来源地址https://www.toymoban.com/news/detail-778847.html
到了这里,关于深入理解 Android 架构 Clean Architecture(补充篇)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!