u014078887的博客

GoF解释：定义一个产生对象的接口，但是让子类决定要产生哪一个类的对象。工厂方法模式让类的实力化延迟到子类是中实施。模式说明：单独声明一个接口，提供某一个子类的实力化工作。在实际项目中，有时候这部分功能会被放在统一的中介类中。但是这样有点不合理，中介类应该只需要负责系统和模块之间的沟通，而不应该参与到具体逻辑的实现。在这里我们使用工厂模式就十分的便利。流程图分析：提供一个抽象工厂类并让客户端持有，实力化根据不同的需求使用不同的工厂进行实力化。案例分析：实现一个资源工厂1.需求分析：我们实现一

GoF解释：让一群对象都有机会处理一个请求，并减少请求发送者与接受者之间的耦合程度。将所有的接受者对象串联起来，让请求沿着串传递，知道有一个对象可以解决请求的问题为止。模式说明：对于一个问题或者一项需求，我们可以制造一条流水线，流水线上每个节点都可能是解决问题的方式，或者是满足需求的一部分。GoF四人组的解释只解释了对问题的处理，而责任链模式在当前的应用很多都是处理需求的组装，熟悉Java后台开发，尤其是Netty框架，大量的应用了责任链模式对对象进行组装。我们先来了解一下这个模式，再来仔细说一下这个

GoF解释：定义一个能够在一个对象结构中，对于所有元素执行的操作。访问者让你可以定义一个新的操作，而不必更改到被操作元素的接口。模式说明：当我们需要对一组对象进行统一的操作时，我们定义一个管理类，在开发的过程中，我们因为需求可能不断的增加，那我们的管理类是不是就要不断的增加，这理论上违反了开闭原则。访问者模式通过提供不同的访问者，使用同一个公共接口，访问到不同的数据或者进行不同的操作。重要的名词：visitor：访问者，为需要集中处理的对象提供操作方法。案例分析：为一个基类的所有实现子类提供计数

GoF解释：将请求封装成对象，让你可以将客户端的不同请求参数化，并配合对列、记录、复原等方法来执行请求的操作模式说明：当我们不希望命令和执行强烈的耦合在一起，需要操作某件事的时候，生成一个命令，然后将这个命令加入对列中，在一个恰当的时机去执行，并且可以存在撤销等操作。当我们不使用设计模式的时候，命令和操作时强烈的耦合在一起的，大多数情况下命令并不能清爽的执行下去,并且也会伴随一些难以撤销的问题。案例分析：简单任务系统1.需求分析：游戏角色可以接收任务，同时可以接很多个，但是每个都需要花费一定的时间

GoF说明：在对象之间建立一个一对多的链接方法，当一个对象发生改变时，其他关联的对象都会自动接收到通知模式说明：游戏中当某个公共的数据改变之后，通常很多需要显示的地方都要做出相应的改变。如果没有设计模式，我们是不是需要一个个的去通知，并且还需要做一下空判断，看所有需要通知的对象是不是已经在场景中了，这是不好的，数据发生改变，正确的做法时我们已经通知已经在场景中并且在关注这个数据的对象就可以了。这就是观察者模式的核心，为公共数据建立一个主题，所有想观察这个主题的对象把自己注册进这个主题。但主题发生改变时

GoF说明：定义一组算法并封装每个算法，让他们可以彼此互相使用。策略模式能让客户端在使用它们时更加独立。模式说明：当我们需要计算一样东西、但是计算过程会依赖外界的变化而变化时，我们就使用策略模式对算法进行封装。定义一个接收者，接收者持有一个算法供客户端对象调用，当外界发生改变时，我们改变接收者的算法。但是客户端调用的接口保持不变，这样开发的时候我们就能专注与不同算法的开发而不是调用流程的开发。三个重要对象：ConcreteStrategy：具体算法Strategy：持有一个算法，并提供接口为客户

GoF说明：在不违反封装的原则下，获取一个对象的内部状态并保留在外部，让对象可以再日后回复之前保留的状态。模式说明：不违反封装，也就是开闭原则，但是又把内部细节暴漏出去并做修改，看似有些矛盾，备忘录模式却能做到不矛盾，先看一下备忘录模式的三个重要角色：记录拥有者（Originator）：内部的全部数据就是需要被保存的数据，可以自动将内部数据通过生成Memento同步出来，也可以通过外部传入的Memento更新自身内部数据。内部数据可以通过get、set属性调用。记录保存者（Memento）：用于作

GoF说明：将一个复杂对象的构建流程与他的对象表现分离开来，让相同的构建流程可以产生不同的对象行为表现模式说明：当你需要一个从构建到行为都非常复杂的对象的时候，你肯定希望找到一个点，用这个点将这个对象的构建和行为区分开。大家可能第一就想到了工厂模式，是的，建造者主要服务于构建复杂的对象，而这个构建行为，通常是在工厂模式下完成的。有所不同的是：通过建造者模式我们可以让不同的角色构建更加灵活多变。案例说明：构建一个复杂的游戏角色1.功能需求：构建一个游戏角色，这个游戏角色包含属性、武器、以及所需的游戏

GoF说明：在一个操作方法中定义算法的流程，其中某些步骤由子类完成。模版方法模式让子类在不变更算法流程的情况下，能够自定义某些步骤的细节。模式说明：当项目中某个功能的流程是固定的，但是在不同的子类实现中又有区别。我们就可以定义模版方法模式，将功能指向的方法设置为sealed，不可被重写。将每个步骤都定义成一个protected级别，可供子类重写，但是不可被对象持有者调用。这样子类就可以自定义每个步骤的细节，以此满足不同的功能需求。案例说明：生成游戏物体1.需求分析：功能使用者只需要调用Born方法

GoF说明：抽象与实现分离，使二者可以独立变化注：GoF的解释有点让人误解，这个说法难道不是 “只依赖接口而不依赖实现的” 的另一种说明，或者是进一步解释依赖倒置原则吗？我的理解：桥接模式是更高层次的、更复杂的、具有组合性质的抽象设计模式模式说明：当我们制作一个功能，这个功能是两个类群组中任意两个实现类组合起来完成的，这个时候我们就可以使用桥接模式对两个类群组的抽象基类进行组合，并实现功能。案例说明：开发游戏中人物手持武器进行攻击的行为1.需求说明：游戏内角色或者NPC都可以携带武器进行攻击

GoF解释：确保类只有一个实例对象，并提供一个全局方法去调用这个对象。模式说明：单例模式通常被使用于一些全局一定唯一的，只关心调用功能，而不关心这个从哪里生成的类，并且这个类通常不应该参与到实际游戏交互子系统的协同工作，负责的功能大量单一且需要统一调度。在项目中，符合这个需求的一般是工具类，如音效管理，UI管理，本地表数据读取等等。案例说明：音效管理，现有MusicManager类统一管理音效的播放1.不使用单例：每个对象都需要持有一个MusicManager对象，这个对象可以是自己New出来，也

GoF解释：外观模式为子系统定义了一组统一的调用接口，这个接口会让子系统变得更加容易使用为什么用这个设计模式：当一个功能模块会调用多个子系统的时候应该怎么做？不用设计模式的情况下，我们需要持有或者访问这些子系统的实例对象或者单例对象，分别访问不同的系统，完成不同的功能。尤其是当一个功能需要调用不同的子系统的时候，代码操作会变得复杂。这违反了面向对象编程的一个特性：迪米特规则，程序解释是对于上层调用者而言，知道的细节越少越好。模式说明：隐藏功能调用所需要的子系统实现细节，提供一个简洁明了的接口供上层

GoF经典说明：让一个对象随着内部状态的改变而改变，而该对象也像是换了类一样模式说明：当一个对象的状态发生改变的时候，对象行为也随之发生改变。但是这个对象对外的操作方式及信息沟通并不发生改变。对象的行为切换是通过内部状态类的切换而切换，当一个对象的内部状态从一个状态切换到另一个状态时，这个对象就会表现出这个状态下预定的行为。这个切换行为最好由状态自己确定，而不是由对象或者更高层的操纵者决定。否则会增加系统的复杂性及耦合性。对于进程而言，只需要知道这个对象对外公开的操作方式及信息沟通就可以了。重要概念