iOS代理模式,ios使用的是哪些设计模式

1,ios使用的是哪些设计模式MVC模式代理模式单例模式观察者模式(通知、KVC)target action模式工厂模式单例模式、委托模式、观察者模式、mvc , (策略模式 、工厂模式等)【iOS代理模式,ios使用的是哪些设计模式】
2,iOS系统的代理模式代理模式是OC中一种常见的设计模式,那么什么是代理模式呢?举个栗子,假设你是一个日发货量过万的淘宝卖家(A),但是每天的派件不可能你本人或者让你的员工去派件,因此你发布了一条信息(B) , 上面注明各种要求,各大快递公司看到有那么大的利益纷纷上门沟通,最后你选择了一件快递公司(C) 。那么在上面的例子中,我们即是委托人 , 发布的信息即协议(protocol) , 上面规定了派件人需要完成的事,而最后选择的快递公司也就是代理人(delegate),代理我们去派件 。根据以上类图,可以知道在代理模式中的角色有以下三种:1.抽象对象角色:声明了目标对象和代理对象的`共同接口,这样一来在任何可以使用目标对象的地方都可以使用代理对象 。2.目标对象角色:定义了代理对象所代表的目标对象 。3.代理对象角色:代理对象内部含有目标对象的引用 , 从而可以在任何时候操作目标对象;代理对象提供一个与目标对象相同的接口,以便可以在任何时候替代目标对象 。代理对象通常在客户端调用传递给目标对象之前或之后,执行某个操作 , 而不是单纯地将调用传递给目标对象 。分类:1.远程代理(Remote Proxy):为不同地理的对象提供局域网代表对象2.虚拟代理(Virtual Proxy):根据需要将资源消耗很大的对象进行延迟,真正需要的时候再创建3.保护代理(Protect Proxy):控制用户的访问权限4.智能引用代理(Smart Reference Proxy):提供对目标对象额外的服务在使用代理模式的时候,九成以上使用到的都是智能引用代理 。
3,ios block和代理的区别首先两者作用是一样的,都是进行单一回调 。不通的是,delegate是个对象,然后用过一个对象自己调用代理协议函数来完成整个流程 。block是传递一个函数指针 , 利用函数指针执行来进行回调 。还有在内存管理上需要注意 , delegate不需要保存引用 。block对引用数据有copy的处理 。我认为block主要是替代selector 。对于一个包含少量代码的方法可以放到一个block中而不用重新定义个方法 , 增加代码的可读性 。比如通知中心(nsnotificationcenter)事件的回调(addobserver)可以指定一个函数,也可以直接用block
4 , iOS 设计模式一代理模式代理模式是一种消息传递方式 , 一个完整的代理模式包括:委托对象、代理对象和协议 。协议:用来指定代理双方可以做什么,必须做什么 。委托对象:根据指定的协议,指定代理去完成什么功能 。代理对象:根据指定的协议,完成委托方需要实现的功能 。从上图中可以看到三方之间的关系 , 在实际应用中通过协议来规定代理双方的行为,协议中的内容一般都是方法列表,当然也可以定义属性 。协议是公共的定义,如果只是某个类使用,我们常做的就是写在某个类中 。如果是多个类都是用同一个协议,建议创建一个Protocol文件,在这个文件中定义协议 。遵循的协议可以被继承,例如我们常用的UITableView ,由于继承自UIScrollView的缘故 , 所以也将UIScrollViewDelegate继承了过来,我们可以通过代理方法获取UITableView偏移量等状态参数 。协议只能定义公用的一套接口,类似于一个约束代理双方的作用 。但不能提供具体的实现方法 , 实现方法需要代理对象去实现 。协议可以继承其他协议 , 并且可以继承多个协议 , 在iOS中对象是不支持多继承的,而协议可以多继承 。协议有两个修饰符@optional和@required ,创建一个协议如果没有声明,默认是@required状态的 。这两个修饰符只是约定代理是否强制需要遵守协议 , 如果@required状态的方法代理没有遵守 , 会报一个黄色的警告 , 只是起一个约束的作用,没有其他功能 。无论是@optional还是@required,在委托方调用代理方法时都需要做一个判断,判断代理是否实现当前方法,否则会导致崩溃 。在iOS中代理的本质就是代理对象内存的传递和操作,我们在委托类设置代理对象后,实际上只是用一个id类型的指针将代理对象进行了一个弱引用 。委托方让代理方执行操作,实际上是在委托类中向这个id类型指针指向的对象发送消息,而这个id类型指针指向的对象,就是代理对象 。通过上面这张图我们发现 , 其实委托方的代理属性本质上就是代理对象自身 , 设置委托代理就是代理属性指针指向代理对象,相当于代理对象只是在委托方中调用自己的方法 , 如果方法没有实现就会导致崩溃 。从崩溃的信息上来看 , 就可以看出来是代理方没有实现协议中的方法导致的崩溃 。而协议只是一种语法 , 是声明委托方中的代理属性可以调用协议中声明的方法,而协议中方法的实现还是有代理方完成,而协议方和委托方都不知道代理方有没有完成,也不需要知道怎么完成 。由于代理对象使用强引用指针 , 引用创建的委托方对象,并且成为委托对象的代理 。这就会导致委托对象的delegate属性强引用代理对象,导致循环引用的问题,最终两个对象都无法正常释放 。我们将委托对象的delegate属性,设置为弱引用属性 。weak和assign是一种“非拥有关系”的指针,通过这两种修饰符修饰的指针变量,都不会改变被引用对象的引用计数 。但是在一个对象被释放后,weak会自动将指针指向nil,而assign则不会 。在iOS中,向nil发送消息时不会导致崩溃的,所以assign就会导致野指针的错误unrecognized selector sent to instance。所以我们如果修饰代理属性,还是用weak修饰,比较安全 。5,iOS代理和通知的区别代理耦合度更高A、B、C、D需要有生命周期的耦合,代理用于比较明确的实例间的通知关系,比起通知可读性会更好;通知虽然耦合低但不能被滥用,适合单纯广播行为,因为可能B、C、D类不止一个实例,但期望的只是通知部分实例;通知还考虑多线程调用;从模式上,一种是代理模式 , 一种算是观察者模式 。首先两者作用是一样的,都是进行单一回调 。不通的是,delegate是个对象,然后用过一个对象自己调用代理协议函数来完成整个流程 。block是传递一个函数指针,利用函数指针执行来进行回调 。还有在内存管理上需要注意,delegate不需要保存引用 。block对引用数据有copy的处理 。6,Java静态代理和iOS代理模式这两个概念的理解上的疑惑看了JAVA版的设计模式的 代理模式 和IOS @protrol 比较,java 的看了都晕了 。不完全一致 , 委托和代理 称呼上就好像反的 。用JAVA 的中接口 在view中实现方法 , 就要把接口中所有的方法都复写一下 , 这个不太好用,还不知道其它什么模式来实现像Ios @protrol 的功能 。java静态代理模式,举例给你,看下如何理解:publicclassTspublicstaticvoidmain(String[] args)throwsException// 通过中介公司生产一批衣服ClothingProduct cp =newProxCompany( newLiNingCompany());cp.productClothing();}}/** * 定义生产一批衣服功能的接口 * */interfaceClothingProductvoidproductClothing();// 有生产一批衣服的功能}/** * * 代理类:中介公司 * */classProxCompanyimplementsClothingProductprivateClothingProductcp;// 中介公司不会生产衣服,需要找一家真正能生产衣服的公司ProxCompany(ClothingProduct cp)super ();this . cp= cp;}@OverridepublicvoidproductClothing()System.out .println( "收取1块钱的中介费");cp .productClothing();}}/** * * 李宁公司是生产服装的目标类 * */classLiNingCompanyimplementsClothingProduct@OverridepublicvoidproductClothing()System.out .println( "生产一批衣服 。。。。");}}上面程序的做法,使用的模式是静态代理模式静态代理模式在现实编程中的弊端:它的特征是代理类和目标对象的类都是在编译期间确定下来的,不利于程序上的扩展,上面示例中,如果客户还想找一个“生产一批鞋子”的工厂,那么还需要新增加一个代理类和一个目标类 。如果客户还需要很多其他的服务,就必须一一的添加代理类和目标类 。那就需要写很多的代理类和目标类代理模式到底做了什么?我眼中的代理模式只有两个关注点:协议和代理者协议定义了一组方法,由某一个类负责实现 。代理者作为某个类的一个属性,通常是另一个类的实例对象 , 可以负责完成原来这个类不方便或者无法完成的任务 。首先谈一谈代理者,在脑中重新回想一下代理模式的实现过程 。在页面B中定义一个代理对象的时候,好像和定义一个普通的property非常类似(除了 weak和id《delegate》>) 。这也正是我对代理的概括:代理本来就是一个属性而已,并没有非常神秘 。当然,代理者并不只是一个类普通的属性,否则我只需要重写一下B的初始化方法即可达到同样的效果:self.BVC = [[BViewController alloc]initWithDelegate:self];然后在BViewController.m中定义一个AViewController *AVC并在初始化方法中赋值即可 。注意到代理者在定义的时候,格式往往是这样的:id <SomeDelegate> delegate;所以我对代理的优势的理解是:代理的核心优势在于解耦与直接声明一个属于某个固定的类的代理者相比,声明为id的代理者具备两个明星的优势 。允许多个不同的类成为本类的代理 。试想一下在本文例子中,如果页面B可以跳转回N个页面,如果还是通过声明一个普通对象的方式,那怎么办?允许代理者的类还不固定 。试想一下 , UITableView也有delegate,它根本不知道那个类会成为它的代理者 。再看一看协议 。协议更加简单了 。协议只是定义了一组方法 。在代理模式中,完全可以不用在页面B中定义一个协议,然后A再去遵循这个协议 。直接调用A的方法即可 。个人认为协议的优点在于以下几点:可以利用Xcode的检查机制 。对于定义为@required的方法,如果实现了协议而没有实现这个方法,编译器将会有警告 。这样可以防止因为疏忽 , 忘记实现某个代码的情况,而由于OC的运行时特性,这样的错误往往在运行阶段才会导致程序崩溃 。有利于代码的封装 。如果一个类 , 实现了某个协议 , 那么这个协议中的方法不必在.h中被声明 , 就可以被定义协议的类调用 。这样可以减少一个类暴露给外部的方法 。有利于程序的结构化与层次化 。一个协议往往是解决问题的某个方法,对于一个其他的不过却类似的问题,我们只用再次实现协议即可 , 避免了自己再次构思一组方法 。协议的继承机制使得这一有点更加强大 。说了怎么多,总结起来只有一句:代理模式并不神秘,只是一个经过了优化的小技巧(让某个类持有另一个类的指针) 。代理和协议也只是让程序耦合度更低,结构感更强而已 。

    推荐阅读