设计模式

1.描述一下iOS SDK中如何实现MVC的开发模式

MVC是模型、视图、控制开发模式。
对于iOS SDK：
所有的用户数据都是模型层，它应该独立于视图。
所有的View都是视图层的，它应该独立于模型层，由视图控制层来控制。
所有的ViewController都是控制层，由它负责控制视图，访问模型数据。

2、请简述你对MVC设计模式的理解

简要：MVC模式考虑三种对象：模型对象、视图对象和控制器对象。
模型对象负责应用程序的数据和定义操作数据的逻辑；
视图对象知道如何显示应用程序的模型数据；
控制器对象是M与V之间的协调者.

3、描述一下iOS SDK中如何实现MVC的开发模式

MVC是模型、视图、控制开发模式，对于iOS SDK，所有的View都是视图层的，它应该独立于模型层，由视图控制层来控制。所有的用户数据都是模型层，它应该独立于视图。所有的ViewController都是控制层，由它负责控制视图，访问模型数据。

4、MVC优点不正确的是 D

A 低耦合性
B 高重用性和可适用性
C 较低的生命周期成本
D 代码高效率

5、哪些类不适合使用单例模式？即使他们在周期中只会出现一次。

单例是只有一个实例，并向整个系统提供这个实例。
哪些类不适合<不知>

6、MVC模式的理解

答:
MVC，全称Model（模型）-View（视图）-Controller（控制器），这是一种开发模式，他的好处是可以将界面和业务逻辑分离。
Model（模型）：
是程序的主体部分，主要包含业务数据和业务逻辑。在模型层，还会涉及到用户发布的服务，在服务中会根据不同的业务需求，更新业务模型中的数据。
View(视图）：
是程序呈现给用户的部分，是用户和程序交互的接口，用户会根据具体的业务需求，在View视图层输入自己特定的业务数据，并通过界面的事件交互，将对应的输入参数提交给后台控制器进行处理。
Controller（控制器）：
Controller是用来处理用户输入数据，已经更新业务模型的部分。控制器中接收了用户与界面交互时传递过来的数据，并根据数据业务逻辑来执行服务的调用和更新业务模型的数据和状态。

7、谈谈你了解的设计模式，你用过哪些，他们的优缺点。

（一）代理模式
应用场景：当一个类的某些功能需要由别的类来实现，但是又不确定具体会是哪个类实现。
优势：解耦合
敏捷原则：开放-封闭原则
实例：
tableview的数据源delegate，通过和protocol的配合，完成委托诉求。
列表row个数delegate
自定义的delegate

（二）观察者模式
应用场景：一般为model层，对controller和view进行的通知方式，不关心谁去接收，只负责发布信息。
优势：解耦合
敏捷原则：接口隔离原则，开放-封闭原则
实例：
Notification通知中心，注册通知中心，任何位置可以发送消息，注册观察者的对象可以接收。
kvo，键值对改变通知的观察者，平时基本没用过。

（三）MVC模式
应用场景：是一中非常古老的设计模式，通过数据模型，控制器逻辑，视图展示将应用程序进行逻辑划分。
优势：使系统，层次清晰，职责分明，易于维护
敏捷原则：对扩展开放-对修改封闭
实例：
model-即数据模型，view-视图展示，controller进行UI展现和数据交互的逻辑控制。

（四）单例模式
应用场景：确保程序运行期某个类，只有一份实例，用于进行资源共享控制。
优势：使用简单，延时求值，易于跨模块
敏捷原则：单一职责原则
实例：
[UIApplication sharedApplication]。
注意事项：确保使用者只能通过getInstance方法才能获得，单例类的唯一实例。
java，C++中使其没有公有构造函数，私有化并覆盖其构造函数。
object c中，重写allocWithZone方法，保证即使用户用alloc方法直接创建单例类的实例，
返回的也只是此单例类的唯一静态变量。

（五）策略模式
应用场景：定义算法族，封装起来，使他们之间可以相互替换。
优势：使算法的变化独立于使用算法的用户
敏捷原则：接口隔离原则；多用组合，少用继承；针对接口编程，而非实现。
实例：
排序算法，NSArray的sortedArrayUsingSelector；
经典的鸭子会叫，会飞案例。

注意事项：

1，剥离类中易于变化的行为，通过组合的方式嵌入抽象基类
2，变化的行为抽象基类为，所有可变变化的父类
3，用户类的最终实例，通过注入行为实例的方式，设定易变行为
防止了继承行为方式，导致无关行为污染子类。完成了策略封装和可替换性。

（六）工厂模式
应用场景：工厂方式创建类的实例，多与proxy模式配合，创建可替换代理类。
优势：易于替换，面向抽象编程，application只与抽象工厂和易变类的共性抽象类发生调用关系。
敏捷原则：DIP依赖倒置原则
实例：
项目部署环境中依赖多个不同类型的数据库时，需要使用工厂配合proxy完成易用性替换
注意事项：
项目初期，软件结构和需求都没有稳定下来时，不建议使用此模式，因为其劣势也很明显，增加了代码的复杂度，增加了调用层次，增加了内存负担。所以要注意防止模式的滥用。

8、mvc设计模式是什么?你还熟悉什么设计模式

答:系统分为三个部分: Model. View. Controller.在cocoa中,你的程序中的每一个object
(对象)都将明显地仅属于这三部分中的一个，而完全不属于另外两个。MVC课一帮助确保帮助实现程序最大程度的可重用性，各MVC元素彼此独立运作，通过分开这些元素，可以构建可维护，可独立更新的程序组建。
Delegate设计模式；
Target-action设计模式；
单例模式；

9、请至少列举5个常用的设计模式。

1）代理模式
2）观察者模式
3）MVC模式
4）单例模式
5）工厂模式

10、谈谈你了解的设计模式,你用过哪些,他们的缺点

1.MVC:

优点：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。

缺点:
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

2.观察者模式
优点：
1、观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体观察者列表，每一个具体观察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。
由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。如果被观察者和观察者都被扔到一起，那么这个对象必然跨越抽象化和具体化层次。
2、观察者模式支持广播通讯。被观察者会向所有的登记过的观察者发出通知，

缺点：
1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
2、如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察者模式是要特别注意这一点。
3、如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。
4、虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。

3.单例模式:
主要优点：
1、提供了对唯一实例的受控访问。
2、由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
3、允许可变数目的实例。

主要缺点：
1、由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。
2、单例类的职责过重，在一定程度上违背了“单一职责原则”。
3、滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。

11、谈谈MVC设计模式的优缺点

编程以来就一直被灌输MVC设计模式，具体MVC使用到底好在哪里？又有那些不足之处，可以通过下面的介绍得以了解。

一、mvc原理
mvc是一种程序开发设计模式,它实现了显示模块与功能模块的分离。提高了程序的可维护性、可移植性、可扩展性与可重用性，降低了程序的开发难度。它主要分模型、视图、控制器三层。
1、模型(model)它是应用程序的主体部分，主要包括业务逻辑模块（web项目中的Action,dao类）和数据模块（pojo类）。模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性
2、视图(view) 用户与之交互的界面、在web中视图一般由jsp,html组成
3、控制器(controller)接收来自界面的请求，并交给模型进行处理，在这个过程中控制器不做任何处理只是起到了一个连接的做用.

二、MVC的优点
1、可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。

2、视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。

3、模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。

4、潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。

三、MVC的不足之处

1、增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

2、视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

3、视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

4、目前，一般高级的界面工具或构造器不支持模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成MVC使用的困难。

24.谈谈你对MVC开发模式的理解及你是如何在iOS项目中采用MVC模式开发的？
22.谈谈你对代理设计模式的理解
13.你是怎么理解MVC的，在Cocoa中MVC是怎么实现的？
16.谈一下你常用的一些设计模式及应用场景