iOS设计模式与架构

  • 讲讲MVC、MVVM、MVP几种设计模式,以及你在项目里面具体是怎么写的
  • 你自己用过哪些设计模式
  • 一般开始做一个项目,你的架构是如何思考的

架构

架构(architecture)
软件开发中的设计方案
架构可大可小,类与类之间的关系、模块与模块之间的关系、客户端与服务端的关系都可归结为架构

没有哪一个架构是最好的,只有最适合自己的

常见的架构名词
MVC、MVP、MVVM、VIPER、CDD
还有
三层架构、四层架构

MVC

MVC分两个版本,一种是苹果版本的,一种是常用版本的,具体有什么相同与不同呢?我们往下看。

MVC-苹果版

MVC是指的:
Model
View
Controller

三者的关系大致是:
在这里插入图片描述Controller拥有View(直接拥有)
View发生改变可以通知到Controller(例如:tableview的代理)

Controller拥有Model(直接拥有)
Model发生改变可以通知到Controller(通知)

Controller是Model和View的桥梁
Model和View没有交互

优点:View和Model可以重复利用,可以独立使用
缺点:Controller的代码过于臃肿

苹果的UITableViewContorller使用的是这种方法,使用这种方法,Model可以随便写,不拘泥于格式和名字以及model数量,随便改,都不会影响到View层(tableView)的东西。


MVC-常用版

三者的关系大致是:
在这里插入图片描述Controller拥有View(直接拥有)
View发生改变可以通知到Controller(例如:tableview的代理)

Controller拥有Model(直接拥有)
Model发生改变可以通知到Controller(通知)

View可以直接拥有Model(直接拥有),而不需要必须经过Controller

优点:对Controller进行瘦身,将View内部的细节封装了起来,外界不知道View内部的具体实现
缺点:View依赖于Model

使用这种方法,View可以直接拥有Model,Controller被解放出来,缺点是View和Model进行了绑定,以后再重复使用View大概率需要同样的Model。


MVP

MVP是指的:
Model
View
Presenter:主持人,充当一个中间角色
三者的关系大致是:
在这里插入图片描述跟MVC-苹果版差不多。Model与View不直接交互
把一部分业务放在了Presenter中

Presenter继承NSObject
Controller拥有Presenter
Presenter弱引用Controller
差不多是Presenter做了部分Controller的工作,去整合Model和View


MVVM

MVVM是指的:
Model
View
VieModel
三者的关系大致是:
在这里插入图片描述

跟MVP看着差不多,但是还是有区别。

VieModel继承NSObject

Controller拥有ViewModel

MVVM核心的地方:属性监听
在View上,对ViewModel上的属性值进行监听,如果ViewModel上的属性值改变了,那么,View上的东西做响应的改变。
这就是View跟ViewModel之间的交互

ViewModel上的属性值改变(Model赋值),要告诉View上的东西做响应的改变
方法有:RAC、KVO、Facebook推出的KVOController
RAC比较重量级
KVO麻烦一点点
Facebook推出的KVOController,使用简单

MVVM 最重要的一个特性就是数据绑定,通过将 View 的属性绑定到 ViewModel
正确认识 MVC/MVP/MVVM
通俗易懂图解MVVM和RAC双向绑定介绍(附Demo)


三层架构

在这里插入图片描述

四层架构

在这里插入图片描述


设计模式

设计模式(Design Pattern)
是一套被反复使用、代码设计经验的总结
使用设计模式的好处是:可重用代码、让代码更容易被他人理解、保证代码的可靠性
一般与编程语言无关,是一套比较成熟的编程思想

设计模式可以分为三大类:

  • 创建型模式:对象实例化的模式,用于解耦对象的实例化过程
    例如:单例模式、工厂方法模式等等

  • 结构型模式:把类和对象结合在一起形成一个更大的结构
    例如:代理模式、适配器模式、组合模式、装饰模式等等
    (代理模式不是指的delegate,而是指的NSProxy)

  • 行为型模式:类或对象之间如何交互,及划分责任和算法
    例如:观察者模式(KVO)、命令模式、责任链模式等等


学习资料推荐

数据结构与算法:
严蔚敏《数据结构》
《大话数据结构与算法》
《恋上数据结构1、2、3季》

网络:
《HTTP权威指南》
《TCP/IP详解卷1:协议》

架构与设计模式:
Trip-to-iOS-Design-Patterns
图说设计模式

1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值