reusable

什么是建造者模式 经典建造者模式的优缺点 对建造者模式的扩展 什么是建造者模式 建造者模式将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建具有复合属性的对象。 虽然与工厂模式、抽象工厂模式、单件模式同为创建型模式，但建造者模式与之前学习的模式相比，更为关注创建过程的细节，它一般用于创建复杂对象，从独立创建每个部分到最后的组装，它承担每个步骤的工作。由于它把创建每个部分都独立为一个单一的过程，因此不仅可以完成较为精细的创建，还可以根据创建步骤编排，生成不同的目标实例。 GOF对建造者模式的描述是： Separate the construction of a complex object from its representation so that the same construction process can create different representations.. — Design Patterns : Elements of Reusable Object-Oriented Software 创建者模式非常适用于产品局部加工过程变化较大，但组装过程相对固定的场景。 比如电脑的组装，基本的组装过程是固定的，但是具体主板、CPU

行为型模式 行为型模式关注于应用运行过程中算法的提供和通信关系的梳理。 相比于创建型模式和结构型模式，行为型模式包含了最多的设计模式种类，包括： 职责链模式 模板方法模式 解释器模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式 职责链模式 职责链模式为了避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，会将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。 GOF对外观模式的描述为： Avoid coupling the sender of a request to its receiver by giving morethan one object a chance to handle the request. Chain the receivingobjects and pass the request along the chain until an object handles it. — Design Patterns : Elements of Reusable Object-Oriented Software 在日常生活中，也会遇到类似的具有一系列“工序”的场景，比如用洗衣机洗衣服，需要经过注水、洗涤、漂洗、排水等过程，但作为使用者，我们并不需要关注这些步骤，需要做的只是把衣服放到洗衣机

什么是建造者模式 经典建造者模式的优缺点 对建造者模式的扩展 什么是建造者模式 建造者模式将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建具有复合属性的对象。 虽然与工厂模式、抽象工厂模式、单件模式同为创建型模式，但建造者模式与之前学习的模式相比，更为关注创建过程的细节，它一般用于创建复杂对象，从独立创建每个部分到最后的组装，它承担每个步骤的工作。由于它把创建每个部分都独立为一个单一的过程，因此不仅可以完成较为精细的创建，还可以根据创建步骤编排，生成不同的目标实例。 GOF对建造者模式的描述是： Separate the construction of a complex object from its representation so that the same construction process can create different representations.. — Design Patterns : Elements of Reusable Object-Oriented Software 创建者模式非常适用于产品局部加工过程变化较大，但组装过程相对固定的场景。 比如电脑的组装，基本的组装过程是固定的，但是具体主板、CPU

外观模式（或门面模式、包装模式）是设计模式中非常朴素地体现面向对象“封装”概念的模式，它的基本原理是将复杂的内部实现以统一接口的方式暴露出来，最大程度地减少客户程序对某些子系统内部众多对象的依赖关系。 外观模式在开发过程中运用频率非常高，比如各种第三方SDK大多会使用外观模式。通过一个外观类是的整个系统的接口只有一个统一的高层接口，这样能够降低用户的使用成本，也能够对用户屏蔽很多实现细节。 再比如经常会用到的三层结构也是外观模式的应用。 GOF对外观模式的描述为： Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. — Design Patterns : Elements of Reusable Object-Oriented Software UML类图： 通过外观模式为子系统中的一组接口提供一个高层接口，该接口使子系统更易于使用。它的主要动机是减少“子系统”内部与外部间对象通信的依赖复杂程度 再比如计算机就是一个通过提供一个高层接口以屏蔽内部复杂性的例子，计算机包括CPU、硬盘、内存等各种部件，但作为用户，不需要与这些零部件打交道

原型模式 原型模式的适用场景 浅拷贝 深拷贝 用Initialize方法修改初始化状态 原型模式与之前学习的各种工厂方法、单例模式、建造者模式最大、最直观的区别在于，它是从一个既有的对象“克隆”出新的对象，而不是从无到有创建一个全新的对象。与对文件的拷贝类似，原型模式是基于现有的对象拷贝新的对象。 原型模式 GOF对原型模式的描述为： Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.. — Design Patterns : Elements of Reusable Object-Oriented Software 原型模式的构造对象的的过程是，选择一个现成对象（原型对象），通过调用它的“克隆”方法来获得一个和它一样的对象。 其UML类图为： 原型模式的适用场景 原型模式适用与如下场景： Factory、Builder、Singleton返回的都是“初始状态”的对象，但有的时候需要的对象反而是处于某种状态的对象； 如果一个对象的初始化需要很多其他对象的数据准备或其他资源的繁琐计算，则可以使用原型模式直接克隆； 当需要一个对象的大量公共信息，少量字段进行个性化设置的时候

中介者模式 中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。 介绍 意图： 用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 主要解决： 对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。 何时使用： 多个类相互耦合，形成了网状结构 。 如何解决： 将上述网状结构分离为星型结构 。 关键代码： 对象 Colleague 之间的通信封装到一个类中单独处理。 应用实例： 1、中国加入 WTO 之前是各个国家相互贸易，结构复杂，现在是各个国家通过 WTO 来互相贸易。 2、机场调度系统。 3、MVC 框架，其中C（控制器）就是 M（模型）和 V（视图）的中介者。 优点： 1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。 缺点： 中介者会庞大，变得复杂难以维护。 使用场景： 1、系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为

创建型模式 简单工厂模式 工厂方法模式 IOC与工厂方法模式的结合 泛型工厂 委托工厂 创建型模式 创建型模式可以隔离客户程序对需要实例化类型的依赖关系，这类模式一般通过将实例化具体对象的职责委托给第三方对象的方式，使得客户程序或者外部系统在获得所需的具体类型实例的同时，而不必对其发生直接的引用。 创建型模式包括： 工厂方法模式 单例模式 抽象工厂模式 创建者模式 原型模式 按照大多数设计模式书籍采用的顺序，首先从工厂方法模式开始。 简单工厂模式 简单工厂模式并没有被归入23种设计模式之列，但可以作为学习工厂方法模式前的预备。简单工厂模式在管理对象创建方面，提供的是最简单的方案，它仅仅简单的对不同类对象的创建进行了一层薄薄的封装，客户程序在使用时，通过向简单工厂传递一个类型来指定要创建的对象，其UML类图如下： Client需要的是具体的产品ConcreteProductA或者ConcreteProductB，如果直接new()就会依赖对象实例，引入简单工厂后，Client变成了依赖IProduct和SampleFactory。 代码示例： //产品接口 public interface IProduct { }; //具体产品 public class ConcreteProductA : IProduct { } public class ConcreteProductB :

组合模式 透明模式与安全模式 对组合的筛选遍历 无论是在生活中还是项目中，我们经常会遇到具有“部分-整体”概念的对象，比如员工与团队的关系，这就类似树形结构，可能具有很多的嵌套层次和分支，把这种复杂性直接暴露给调用端是不合适的。 组合模式 借助组合模式，可以将这类具有“部分-整体”的对象组合成树形的层次结构，并使得用户可以对单个对象和组合对象采用相同的使用方式。 GOF对组合模式的描述为： Compose objects into tree structures to represent part-whole hierarchies. Compositelets clients treat individual objects and compositions of objects uniformly. — Design Patterns : Elements of Reusable Object-Oriented Software UML类图： 组合模式包含三个角色： Leaf：叶子节点，代表单个个体，它没有子节点。 Composite：组合节点，既可以包含叶子节点，也可以包含其他的组合节点， Component：抽象构件，定义Leaf和Composite共有的方法和属性，可以定义一些默认的行为或属性。 透明模式与安全模式 在使用组合模式时，根据抽象构件类的定义形式

CMA的全称叫做contiguous memory allocator，它是为了便于进行连续物理内存申请的一块区域，一般我们把这块区域定义为reserved-memory。 早期的Linux内核中没有cma的实现，如果驱动想要申请一个大块的物理连续内存，那么只能通过预留专属内存的形式，然后在驱动中使用ioremap来映射后作为私有内存使用。这样带来的后果就是有一部分内存将被预留出来不能作为系统中的通用内存来使用，比如camera、audio设备，它们在工作时是需要大块连续内存进行DMA操作的，而当这些设备不工作时，预留的内存也无法被其他模块所使用。 如何使得操作系统能够充分的利用物理内存呢？比如当一些设备需要使用大块连续物理内存时，可以比较容易的申请到，而当这些设备不工作时，这些内存又可以当做普通的内存那样被系统其他模块申请使用。引入CMA就是为了解决这个问题的，定义为cma区域的内存，也是由操作系统来管理的，当一个驱动模块想要申请大块连续内存时，通过内存管理子系统把CMA区域的内存进行迁移，空出连续内存给驱动使用；而当驱动模块释放这块连续内存后，它又被归还给操作系统管理，可以给其他申请者分配使用。 我前面的文章有介绍过《对于MIGRATE_MOVABLE的理解》，其中有讲到，buddy system在对内存进行管理时，不同size的内存块是分类管理的，其中有一类就是

桥接模式的概念与实现 为什么叫桥接模式 桥接模式的适用场景 继承是面向对象的三大特性之一，但很多时候使用继承的结果却不尽如人意。除了人尽皆知的紧耦合问题外，有的时候还会导致子类的快速膨胀。 设想这样一个场景：最初设计的时候有一个类型Product，但后来随着新需求的出现，X原因导致了它的变化，X有两种情况，则通过继承需要创建两个新的子类ProductX1,ProductX2，但后来有出现了Y因素也会导致Product的变化，如果Y有三种情况，则会出现ProductX1Y1,ProductX1Y2,ProductX1Y3...等，一共2*3=6个类。 使用这种继承的方式，如果再出现新的变化因素，或者某个变化因素出现了新的情况，都会导致子类的快速膨胀，给维护带来很大的挑战。 造成这个问题的根本原因是类型在沿着多个维度变化。为了应对变化，一般会通过抽象的方法，找到其中比较稳定的部分，然后抽象其行为，令客户程序依赖于抽象而不是具体实现。同样的道理，当一个类型同时受到多个因素变化的影响时，也通过把每个因素抽象，让类型依赖于一系列抽象因素的办法尽量处理这个问题，这便是桥接模式解决问题的思路。 桥接模式的概念与实现 GOF对桥接模式的描述为： Decouple an abstraction from its implementationso that the two can vary