外观模式提供了一个统一的接口，用来访问子系统中的一组接口。外观定义了一个高层接口，让子系统更易使用。

在以下两种常见的情形下，会考虑使用这一模式:

• 子系统正逐渐变得复杂。可以使用外观为这些子系统类提供一个较简单的接口.
• 可以使用外观对子系统进行分层。每个子系统级别有一个外观作为入口点。让它们通过其外观进行通讯，可以简化它们的依赖关系

适配器模式将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

适配器不是在详细设计时添加的，而是解决当前已有项目遇到的问题。以下情况可以使用适配器模式:

• 已有的类的接口与新需求不匹配
• 需要一个可复用的类，能够和接口不兼容的其他类进行协作
• 需要适配一个类的几个不同子类，可以使用对象适配器来适配其父类接口

客户使用适配器的过程如下：

1. 客户通过目标接口调用适配器的方法对适配器发出请求
2. 适配器使用被适配者接口把请求转换成被适配者的一个或多个接口
3. 客户收到调用结果，但不会察觉到这是适配器在起转换作用

命令模式将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

命令模式可通过“命令对象”将“动作的请求者”从“动作的执行者”对象中解耦。一个命令对象通过在特定接收者上绑定一组动作来封装一个请求。要达到这一点，命令对象需要将动作和接收者封装进对象中。

也可以创建命令的宏，以便一次执行多个命令。

优点:

• 就是将行为请求者和行为实现者解耦,降低了系统耦合度
• 便于扩展新的命令，以及使用命令组合

缺点:

• 使用命令模式可能会导致某些系统有过多的具体命令类，增加了系统的复杂性

定义

单例模式确保一个类只有一个实例，并提供一个全局访问点。

单例模式的优点：

• 提供了对唯一实例的受控访问
• 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例
• 避免对资源的多重占用

单例模式的缺点：

• 没有接口，不能继承，扩展有很大的困难

所有工厂模式都用来封装对象的创建。实际开发中，实例化一个具体对象不应该公开进行，初始化一个具体对象也经常造成“耦合”问题。适当的使用工厂模式将有助于解决复杂的依赖问题。

下面简单介绍了工厂模式的三种用法：

• 简单工厂方法
• 工厂方法模式
• 抽象工厂模式

基本概念

装饰者模式通过创建一个装饰对象来包裹真实的对象，动态地将责任附加到对象上。若要扩展功能，装饰着提供了比继承更有弹性的替代方案。

以下情况推荐使用装饰者模式：

1. 需要扩展一个类的功能，或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

装饰者模式的优点：

1. Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

装饰者模式的缺点：

1. 比继承更加灵活机动的特性，也同时意味着更加多的复杂性。
2. 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。
3. 装饰模式是针对抽象组件（Component）类型编程。如果要针对具体组件编程时，就应该重新思考应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

基本概念

策略模式定义了算法族，分别封装起来， 让他们可以相互替换，此模式让算法的变化独立于使用算法的客户。

策略模式的重心不是如何来实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活、具有更好的维护性和扩展性。

策略模式的本质：分离算法，选择实现。

策略模式优点:

1. 算法可以自由切换（高层屏蔽算法，角色自由切换）
2. 避免使用多重条件判断（如果算法过多就会出现很多种相同的判断，很难维护）
3. 扩展性好（可自由添加取消算法 而不影响整个功能）

策略模式缺点:

1. 策略类数量增多（每一个策略类复用性很小，如果需要增加算法，就只能新增类）
2. 所有的策略类都需要对外暴露（使用的人必须了解使用策略，这个就需要其它模式来补充，比如工厂模式、代理模式）

基本概念

观察者模式定义了对象之间的一对多依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

观察者模式主要涉及四个关键对象：

1. Subject被观察者：定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。

2. Observer观察者：观察者接收到消息后，即进行update（更新方法）操作，对接收到的信息进行处理。

3. ConcreteSubject具体的被观察者：定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。

4. ConcreteObserver具体的观察者：每个观察在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。

观察者模式的两种类型：

1. 推模型：主题对象向观察者推送主题的详细信息，不管观察者是否需要，推送的信息通常是主题对象的全部或部分数据。

2. 拉模型：主题对象在通知观察者的时候，只传递少量信息。如果观察者需要更具体的信息，由观察者主动到主题对象中获取，相当于是观察者从主题对象中拉数据。

观察者模式的优点：

1. 观察者和被观察者是抽象耦合的。
2. 观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。

观察者模式的缺点：

1. 如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间
2. 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
3. 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

接上文SVN+Cocoapods， 使用SVN存放Specs索引库有一个致命缺陷，如果开发组件库的过程中又在podspec文件里使用dependency依赖了其他私有库， 那么之后在使用pod package打包时会报错无法找到依赖的私有库。这是因为pod package默认搜索官方索引库， 而且手动指定–spec-sources并不支持SVN路径。

为解决打包问题，代码依旧托管到SVN，改将Specs索引库托管到第三方Git。 详细操作流程见下文。

本文主要记录了SVN和Cocoapods的配合使用, 为组件化工作的基础部分. 目录如下：

• SVN目录说明
• 配置ComponentSpecs
• 配置podspec
• 推送podspec
• 发布framework