fallingboats的专栏

概述在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。意图将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》]结构图图1 Bridge模式结构图生活中的例子桥接模式将抽象部分与它

Template Method模板方法模式是一种行为型模式，具体点说是行为类型模式。主要解决在软件构建过程中，对于某一项任务，常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因而无法和任务的整体结构同时实现。       GoF《设计模式》中说道：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法

在面向对象的编程中，软件编程人员更加注重以前的代码的重用性和可维护性。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。一般而言，一个模式有四个基本要素1. 模式名称（pattern name） 一个助记名，2. 问题(problem) 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可

Composite组合模式主要是应对这样的问题：一类具有“容器特征”的对象——即他们在充当对象的同时，又是其他对象的容器的情况。在编写时我们常常会造成：客户代码过多地依赖于对象容器复杂的内部实现，对象容器内部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性的弊端。       GoF《设计模式》中说到：将对象组合成树形结构以表示“部分-整体”的层次结构。Com

Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象的状态处理。  Flyweight享元设计模式是一种结构型设计模式，它主要解决的问题是：由于（同类）对象的数量太大，采用面向对象时给系统带来了难以承受的内存开销。比如有这样一个场景

Facade外观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade外观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化

Adapter适配器模式是一种结构型模式，主要应对：由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是，新环境要求的接口是现存对象所不满足的。       《设计模式》中说道：将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。       在实际的生活中有很多例子，如：我们常使用的移动硬盘，无论是笔记本硬

Prototype原型模式是一种创建型设计模式，它主要面对的问题是：某些结构复杂的对象的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口      Prototype原型模式是一种创建型设计模式，它主要面对的问题是：“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。感觉好像和前几篇所

Builder模式的结构： 建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者（ConcreteBuilder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。具体建造者（Concrete Builder）角色：担任这个角色的是于应用程序

工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory).      这两个模式没有很明显的区别,区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,我们就可能要将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现。下面关于是在网络中查到关于工厂方法模式与抽象工厂模式的概述和区别：工厂方法模式：

工厂方法（FactoryMethod）模式是类的创建模式，其用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一

Strategy策略模式是一种对象行为模式。主要是应对：在软件构建过程中，某些对象使用的算法可能多种多样，经常发生变化。如果在对象内部实现这些算法，将会使对象变得异常复杂，甚至会造成性能上的负担。       GoF《设计模式》中说道：定义一系列算法，把它们一个个封装起来，并且使它们可以相互替换。该模式使得算法可独立于它们的客户变化。       Strategy模式的结构图如下：

具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象作细粒度的控制，有些可能对组件模块提供抽象代理层，在架构层次对对象作proxy。proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。      Proxy代理模式是一种结构型设计模式，主要解决的问题是：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象

Decorator装饰模式是一种结构型模式，它主要是解决：过度地使用了继承来扩展对象的功能。就增加功能而言，Decorator模式比生成子类更为灵活。Decorator装饰模式是一种结构型模式，它主要是解决：“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨

简单工厂模式（Simple Factory Pattern）介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。引入：我们在编程的时候，每当"new"一个对象之后，这个对象就依赖于这个类了。如果在后期的维护过程

Command命令模式是一种对象行为型模式，它主要解决的问题是：在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”的问题。如下图： 有时我们必须向某对象提交请求，但并不知道关于被请求的操作或请求的接受者的任何信息，此时无法抵御变化的紧耦合是不合适的。如：需要对行为进行“记录、撤销/重做、事务”等处理。我们所要做的是将依赖关系转化，将紧耦合变为松耦