项目常见设计模式

项目常见设计模式

MVC

emitEvent
processData
update
segue
View
Controller
Model

主要职责

  • View: 负责试图的更新和ui状态的传递
  • Controller: 处理ui事件并返回数据更新ui,以及页面的跳转
  • Model: 提供数据源

为了减少controller的代码,一般会对controller中的代码进行剥离,比如封装工具类,接口数据的处理通常被提取到Service中,尽管如此还是会略显的臃肿

MVP

emitEvent
process
emiteState
update
View
Presneter
Model

主要职责

  • View: 负责试图的更新和ui状态的传递
  • Prensenter: 同时关联view和model成为它们直接的纽带, 接受ui事件处理业务逻辑,返回数据,对controller的业务逻辑进行一些剥离,view并不直接使用model
  • Model: 提供数据源

Note: 为了减少controller的代码,一般会对controller中的代码进行剥离,比如封装工具类,接口数据的处理通常被提取到Service中,尽管如此还是会略显的臃肿

MVVM

emitEvent
processData
emiteState
updateUI
View
ViewModel
Model

主要职责

  • View: UI展示
  • ViewModel: 业务逻辑的处理(BLoc),监听view的声明周期来绑定ui事件和业务逻辑的处理
  • Model: 提供数据

它是一种典型响应式编程,特别适合ui界面有非常多的数据高频次且有复杂的业务逻辑更新的场景, SwiftUI和Combine的框架也是基于此演变而来,使用时需要注意ViewModel的绑定与解绑,viewModel与其它ViewModel之间的关联

VIPER

流程

mediator
emitEvent
request
known
response
emitState
Module
Router
Presenter
View
Interactor
Entity

主要职责

  • 在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管理。作用域配合具体业务模块的父子级别来设定.对于模块化编成可以说是必不可少的

register
save
register
save
register
save
resolve
Registry
FactoryA
Container
FactoryB
FactoryC
singletonContainer
normalContainer
baseContainer

Interceptor

拦截器,常用语对数据调用链中某个节点的业务逻辑进行处理,面向切面的变成思想,基本上大部分项目都会使用,可以大大减少代码的耦合度以及对流程的控制,下面是其中一个例子,将header字段的处理,日志的输出,token的处理非常清晰进行接耦合操作

processHeaders
processResponse
processlog
HttpRequest
HeaderInterceptor
ApiClient
TokenInterceptor
LoggerInterceptor

基于它的演变还有非常多有用的其设计Pipe,Transformer,Validator,Guard,本质就是对过程的某一节点进行剥离,再加上一些广泛引用专业术语约定的类名,对局部繁琐的逻辑进行简化. 相比较大量的创建工具类,这种方式更加清晰,也便于测试

其它设计模式

Singleton(单例模式),Factory(工厂模式),Builder(建造模式),Prototype(原型),Bridge(桥接模式),Facade(外观模式),Flyweight(享元模式),Proxy(代理),Visitor(访问者模式),Template(模版/继承模式),Strategy(策略模式),State(状态模式模式),Observer(观察者模式),Memento(备忘录模式),Mediator(中介者模式),Iterator(迭代模式),Interpreter(解释器模式),Command(命令模式),Responser(责任链模式)

上面这些设计模式都是基于不同的业务场景所定义的,名字大多是根据具体的业务场景来定义的,掌握这些专业的名词将有助于提升代码规范和源码的阅读理解
所有的这些设计模式基本上都是基于封装,继承,多态结合具体业务场景来制定的,在设计时都尽可能的满足六大基本设计原则。在理解了类的基本特性,基于六大设计原则前提下,再结合具体的业务场景就一定能创建出合适的项目的设计模式。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值