设计模式时一条被反复使用,经过分类编码,用于在特定场景下解决问题,是代码设计的经验总结。
常⽤用的有:单例模式, 代理理模式, 观察者模式,mvc模式
整个个应⽤用在运⾏行行期间只有⼀一个类的实例例,⽤于进⾏资源共享控制
优点:在内存中只有⼀个实例,减少了内存开支 可以在系统中设置全局访问点,优化和共享资源访问
缺点单例例不存在接⼝,所以扩展困难,⽽且因为是共享,所有会⼀一改全改、
实现dispatch_once / 结合static实现
//1.声明一个可以static类型的类变量
static Singleton *sharedSingleton = nil;
+ (Singleton *)sharedSingleton{
//2.声明一个只执行一次的任务
static dispatch_once_t once;
//3.调用dispatch_once执行该任务指定的代码块,该代码库就是创建类的过程
dispatch_once(&once,^{
sharedSingleton = [[self alloc] init];
});
//4.返回实例化后的类对象。
return sharedSingleton;
}
//重写copyWithZone方法
- (id)copyWithZone:(NSZone *)zone
{
return [ instancetype sharedDataTool];
}
因为单利可以在任何地方被使用,而且不用清晰的声明从属关系,这意味着任何与单利交互的副作用都会影响程序中的代码
单利的生命周期
由于单例没有明确的owner(因为单例自己管理自己的生命周期),销毁一个单例是非常艰难的,所以单例只应该保持全局状态,且该状态的生命周期与程序的生命周期一致
单利使用场合:
1)要求生成唯一序列号的场合(强调唯一性)
2)再整个项目需要共享访问或共享数据
3)创建易额对象需要消耗过多的资源,却有可能多次使用
4)需要定义大量的静态常量和静态方法。
单利的应用实例: UIApplication,NSBunder,NSNotificationCenter,NSFileManager等
又称发布模式,是观察者把自己加入被观察者的一个管理队列中,当被观察者对象的状态发生改变时,可以通过轮询这个管理队列来通知所有的对他正在进行观察的对象,以便这些对象各自按照要求作出响应
观察者模式的消息传递方式是一对多的,也可以跨层传递消息
一种通用的设计模式,用于两个对象协同解决问题,允许一个对象在某些特定时刻通知到其他对象,从而让其他对象对这个对象的变化做出反应。因不需要获取其他类的指针,所以可以减少框架复杂度。
代理模式由:协议.代理方,委托方三部分组成
协议:指定代理双方可以做什么,需要做什么
代理方: 根据协议实现委托方需要它实现的功能
委托方: 又称被代理方,根据协议,调用代理方去完成一些功能
1.委托方将要求代理方实现的接口全部定义在协议当中(在协议当中可以声明属性,也可以声明方法)
2.代理方按照协议实现方法(有可能会返回一个处理结果给委托方)
3.委托方在需要的时候调用代理方遵从的协议方法
代理模式应用实例:* tableview 与viewController
其中:tableview 委托方 ,viewController是代理方, dalegate 是协议
在使用代理的时候,存在一个循环引用的问题,当代理,协议,委托都通过强引用(strong)形成一个闭环,则会造成内存泄露的问题,此时我们通常会让委托方弱(weak)引用指向代理方来避免循环引用,
委托方即被代理方,保存一个代理方的弱引用,委托方根据协议向代理方提出调用请求.实际是向自己保存的弱引用对象发送消息
事件是以发信号的方式向对象发送的消息,但存在事件发送方不知道哪个对象将接收到事件的情况。所以需要一个中间者来协调处理,这就产生了代理模式
1.单例不可作为委托方,因为单例只有一份,会导致只有最后一个代理对象有效.
2.注意循环引用,因为代理方会强引用委托方(比如ViewController与tableView的关系,tableview是委托方,viewController是代理方,所有delegate必须是weak),所以delegate必须使用弱引用weak。
通过观察者模式实现,用于跨层传递消息的机制
一般数据处理逻辑是从网络层传递到数据层,然后在经过业务逻辑层加工到达UI层并更新UI。如果有时候网络层返回的数据不经过业务逻辑层,直接到达UI层,这时候就实现了跨层传递
NSnotificaitoncenter是一个单利。向通知中心注册观察者,会根据通知的name参数,把同一name的观察者放到一个数组中,然后以name为key ,观察者数组NSArray为value组成一个集合来保存
发布通知是会根据name找到它所对应的观察者数组。然后调用向通知中心注册观察者所传递的执行方法,这样就完成了通知的发布-响应过程。
通知的发布者只负责发布通知,不关心是否有人处理通知。
### 项目在逻辑上的结构 项目在逻辑上的结构一般分为三层 视图层 业务层 数据层
### 视图层的设计方案 视图层的设计方案一般采用MVC/MVVM/MVP的架构设计
首先,最重要的一点是多个视图能共享一个模型,现在需要用越来越多的方式来访问你的应用程序。 由于模型返回的数据没有进行格式化,所以同样的构件能被不同界面使用。
因为模型是自包含的,并且与控制器和视图相分离,所以很容易改变你的应用程序的数据层和业务规则。
m:数据模型,封住了应⽤用程序的数据,⽐如项⽬中联系人的信息 v:视图对象,也就是用户界面,⽤来展现对象模型的数据,响应用户操作.
在mvc中要求模型对象和视图对象完全隔离,⽬的是方便复⽤
c:视图控制器器,视图对象和模型对象的协调者,⽤用来同步数据模型和视图模型.
在mvc中要求模型对象和视图对象完全隔离,从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步,一旦M改变,V应该同步更新,实际上MVC就是Observer设计模式的一个特例。
4.快速的部署
5.可维护性
6.有利于软件工程化管理
Model:主要提供数据的存储功能,一般都是用来封装网络获取的json数据的集合。Presenter通过调用Model进行对象交互
Presenter:作为model和view的中间人,从model层获取数据之后传给view,使得View和model没有耦合
View:这个View可以是viewcontroller、view等控件。而且v与p一一对应,是将部分的v的业务逻辑放入p中处理,p主要处理业务逻辑,v仅仅负责视图展示和模型数据刷新
好处
Presenter:作为model和view的中间人,从model层获取数据之后传给view,使得View和model没有耦合
View不直接与Model交互,而是通过与Presenter交互来与Model间接交互。
Presenter与View的交互是通过接口来进行的。
通常View与Presenter是一对一的,但复杂的View可能绑定多个Presenter来处理逻辑。
一个模块有4个文件夹,model,controller,presenter,view
mvp 真正的打断了了m v 的交互,
通过p作为中间桥梁,p请求数据,然后组建模型,通知v 刷新,
v 可以是viewcontroller 也可以是view ,而且v与p一一对应,是将部分的v的业务逻辑放入p中处理,并且v不处理任何数据,只负责视图展示和通过新的模型数据刷新,
对于一些v的操作,可以直接发送给p处理,p主要处理业务逻辑,v仅仅负责展示和刷新
主要是为了解决在开发过程中Controller越来越庞大的问题,变得难以维护,
所以MVVM把数据加工的任务从Controller中解放了出来,
使得Controller只需要专注于数据调配的工作,
ViewModel则去负责数据加工并通过通知机制让View响应ViewModel的改变。
严格来说MVVM其实是MVCVM。
Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。
在逻辑上,Controller知道应当展示哪个View,Controller也知道应当使用哪个ViewModel,然而View和ViewModel它们之间是互相不知道的,所以Controller就负责控制他们的绑定关系.
在MVC的基础上,把C拆出一个ViewModel专门负责数据处理的事情,就是MVVM。
然后,为了让View和ViewModel之间能够有比较松散的绑定关系,于是我们使用KVO,Notification,block,delegate和target-action都可以用来做数据通信,从而来实现ViewModel和View的绑定.
(View/ViewController - ViewModel - Model)
View - 用来呈现用户界面,可能是一个view 也可能是一个viewController
Controller - 负责ViewManger和ViewModel之间的绑定,负责控制器本身的生命周期。
ViewModel - 存放各种业务逻辑和网络请求
Model - 用来呈现数据
目的
保持View和Model的高度纯洁,提高可扩展性和复用度
ViewModel是为了拆分Controller业务逻辑而存在的,所以ViewModel需要提供公共的服务接口,以便为Controller提供数据
>
View进行自己所负责的视图数据绑定工作
Controller负责将ViewModel和ViewManger进行绑定,进行数据转发工作。
View很纯洁,需要复用View,若业务逻辑变化则切换ViewManger。
ViewManger也比较纯洁,若业务逻辑不变,而View需要大变,则切换View即可,保证View中的protocol或者block一致即可<最好是通过协议提前规范好>。
这样就实现了互相的封装,两者之间只通过protocol或者block进行交流通信,降低了代码的耦合度。尽量使用protocol和category来制定对象之间的通信规范,来降低代码的侵入性。
ios架构模式- MVC/MVP/MVVM
ios的系统架构从上到依次为:
常用的UIKit位于cocoa touch 层,Foundation位于核心服务层
1.严格定义角色,平衡的将职责划分给不同的实体
2.可测性
3.易用并且维护成本低
项目在逻辑上的结构一般分为三层 视图层 业务层 数据层
视图层的设计方案一般采用MVC/MVVM/MVP/VIPER的架构设计 https://blog.coding.net/blog/ios-architecture-patterns
###MV(X)基本要素 MV(X)指的是MVC/MVP/MVVM
M:Models(模型)?—?数据层或者负责处理数据的数据接口层。比如 Person 和 PersonDataProvider 类
V:Views(视图) - 展示层(GUI)。对于 iOS 来说所有以 UI 开头的类基本都属于这层。
Controller /Presenter/ViewModel(控制器/展示器/视图模型),是modle和view之间的中间者。 一般来说:当用户对view有操作时他负责修改相应的model;当model值发生变化时他负责去更新对应的view。
在mvc中要求模型对象和视图对象完全隔离,目的是方便复用 ### MVC模型之各部分如何进行交互
- M->C :接口(控制器可以调用模型提供的接口)
- C->M :Notification/KVO model可以通过通知来告诉控制器,数据的变化
- C->V: delegate .datasource., IBAction (视图控制器可以实现视图的delegate,datasource,或者xib中视图的事件来响应视图的事件)
V-C: IBoutlet, xib中的视图可以把自己作为视图控制器的插座变量来与视图控制器交互
Model:主要提供数据的存储功能,一般都是用来封装网络获取的json数据的集合。Presenter通过调用Model进行对象交互
Presenter:作为model和view的中间人,从model层获取数据之后传给view,使得View和model没有耦合
View:这个View可以是viewcontroller、view等控件。而且v与p一一对应,是将部分的v的业务逻辑放入p中处理,p主要处理业务逻辑,v仅仅负责视图展示和模型数据刷新
严格来说MVVM其实是MVCVM。