项目常见设计模式
MVC
主要职责
- View: 负责试图的更新和ui状态的传递
- Controller: 处理ui事件并返回数据更新ui,以及页面的跳转
- Model: 提供数据源
为了减少controller的代码,一般会对controller中的代码进行剥离,比如封装工具类,接口数据的处理通常被提取到Service中,尽管如此还是会略显的臃肿
MVP
主要职责
- View: 负责试图的更新和ui状态的传递
- Prensenter: 同时关联view和model成为它们直接的纽带, 接受ui事件处理业务逻辑,返回数据,对controller的业务逻辑进行一些剥离,view并不直接使用model
- Model: 提供数据源
Note: 为了减少controller的代码,一般会对controller中的代码进行剥离,比如封装工具类,接口数据的处理通常被提取到Service中,尽管如此还是会略显的臃肿
MVVM
主要职责
- View: UI展示
- ViewModel: 业务逻辑的处理(BLoc),监听view的声明周期来绑定ui事件和业务逻辑的处理
- Model: 提供数据
它是一种典型响应式编程,特别适合ui界面有非常多的数据高频次且有复杂的业务逻辑更新的场景, SwiftUI和Combine的框架也是基于此演变而来,使用时需要注意ViewModel的绑定与解绑,viewModel与其它ViewModel之间的关联
VIPER
流程
主要职责
- 在Module中: 模块的入口,容器,初始化时来实现对Router/View/Presenter/Interactor/Presenter的组装
- View: 负责显示界面UI,所有事件的交互直接与persenter进行
- Presenter: 中央管理者,也可以说是各模块的纽带,主要提供了一个由协议约束的模块控制类
- 代理View的ui事件,并将ui事件过滤部分传递个router,部分传递给interactor对具体的业务逻辑进行处理
- Interactor: 主要负责presenter传递过来的view事件进行业务逻辑处理再返回
- Router: 它是一个媒介类,主要提供路由的具体实现接口给presenter,当presenter收到来自view的事件后如果是和路由相关会直接执行router
结构比较清晰,比较适合记忆,业务场景复杂时,presenter会比较臃肿,代码量多
DI(Dependency injection)
依赖注入,为对象提供工厂构造方法,以及不同作用域的管理,方便使用者通过全局的单里容器根据类型或者标识获取具体的内容,使用非常广泛
比如Service,ViewModel,View,Model,Router,Module等都可以通过它来提供,可以将它想象为一个超级工厂, 但是需要注意它们的之间的依赖关系和作用域。
通过为了方便管理,品级之间的依赖单独采用一个DI管理。作用域配合具体业务模块的父子级别来设定.对于模块化编成可以说是必不可少的
Interceptor
拦截器,常用语对数据调用链中某个节点的业务逻辑进行处理,面向切面的变成思想,基本上大部分项目都会使用,可以大大减少代码的耦合度以及对流程的控制,下面是其中一个例子,将header字段的处理,日志的输出,token的处理非常清晰进行接耦合操作
基于它的演变还有非常多有用的其设计Pipe,Transformer,Validator,Guard,本质就是对过程的某一节点进行剥离,再加上一些广泛引用专业术语约定的类名,对局部繁琐的逻辑进行简化. 相比较大量的创建工具类,这种方式更加清晰,也便于测试
其它设计模式
Singleton(单例模式),Factory(工厂模式),Builder(建造模式),Prototype(原型),Bridge(桥接模式),Facade(外观模式),Flyweight(享元模式),Proxy(代理),Visitor(访问者模式),Template(模版/继承模式),Strategy(策略模式),State(状态模式模式),Observer(观察者模式),Memento(备忘录模式),Mediator(中介者模式),Iterator(迭代模式),Interpreter(解释器模式),Command(命令模式),Responser(责任链模式)
上面这些设计模式都是基于不同的业务场景所定义的,名字大多是根据具体的业务场景来定义的,掌握这些专业的名词将有助于提升代码规范和源码的阅读理解
所有的这些设计模式基本上都是基于封装,继承,多态结合具体业务场景来制定的,在设计时都尽可能的满足六大基本设计原则。在理解了类的基本特性,基于六大设计原则前提下,再结合具体的业务场景就一定能创建出合适的项目的设计模式。