Swift kingfisher设计浅读

上篇内容讲的flutter的数据库设计,本篇就讲一讲swift方面的.

本篇内容,先不回忆我的项目代码,从kf的设计上体验的一下kingfisher的几点设计之美

Builder

链式调用,不算特别高端,但是写架构的话也会注意这一点.

别名

通过别名解决多平台组件问题

kf命名

架构上,注意不要对系统的对象extension出太多你自定义的方法,在协议上进行拓展,不伤系统,保证原生api的健壮,不要让自己过多的api污染原生的api

rx系列如此

swift 复制代码

extension ReactiveCompatible {
    /// Reactive extensions.
    public static var rx: Reactive<Self>.Type {
        get { Reactive<Self>.self }
        // this enables using Reactive to "mutate" base type
        // swiftlint:disable:next unused_setter_value
        set { }
    }

    /// Reactive extensions.
    public var rx: Reactive<Self> {
        get { Reactive(self) }
        // this enables using Reactive to "mutate" base object
        // swiftlint:disable:next unused_setter_value
        set { }
    }
}

snp是如此

swift 复制代码

var snp: ConstraintViewDSL {
        return ConstraintViewDSL(view: self)
    }

DataReceivingSideEffect

options中设置了一个var onDataReceived: [DataReceivingSideEffect]? = nil 这个类似一个插件,在接收到网络请求回调的时候foreach所有的onDataReceived,做数据处理

这东西在网络请求的moya也有使用

从架构方面来说,这是一种生命钩子下发的应用,因为做底层设计,肯定是不允许业务代码写到底层中,但是有一些业务又必须应用某些钩子,比如权限校验,比如进度的回调等等,这时候设计插件,在底层应用到业务,是十分有效且方便的.

RetrievingContext

上下文的概念,包含KingfisherParsedOptionsInfo以及source 简单的设计了一层上下文,只不过option已经涵盖了几乎所有的该此图片加载需要的参数,context在kf中的概念也就没那么重了

我拿出来提是context这个概念词也是架构层面比较重要的,承载了某个行为所需要的信息内容,比如flutter中设计上下层组件,InheritedWidget

假设设计一个tabbar组件,currentIndex,tab的所有主题配置(背景色,长宽高,item字体等等等),就可以设置在上层组件树中,通过InheritedWidget获取到总的信息,在架构上,这就是context的概念.

结尾

今天大概看了kingfisher的源码,也并不是朝着一行行探索kingfisher的源码实现的,只是从kingfisher的源码中,略微说明一下,我理解的好代码的架构,是如何一点点设计出来的,也算是一种抛砖引玉.

我记录blog目前有一个问题,脑子里想的很多很多,但是写出来又感觉在写水文,这也是我个人的能力缺陷,希望能慢慢改善.

如果各位读者喜欢本篇这方面的内容,我会继续记录的.