布衣大侠的博客

在实际的开发过程中经常遇到这样一个问题：游戏的很多个界面同时开着的，这些界面又共享一部分数据信息，需要实时的动态的刷新这些数据信息。设计思路：构造全局的事件监听器，在每个界面打开时做好相应数据的监听事件，当数据发生改变时只需要派发相应的事件即可。using System.Collections.Generic;public delegate void GameEventHandler(params object[] args);public class GlobalEvent{ ///

本人是从事Unity客户端开发工作的，从本文开始将会记录一些在实际项目中用到的一些通用框架和功能组件，整理完善一套比较适用的基础框架（最近有空闲时间，将以前的项目的代码重构一下，如有不合适的地方请大神们多多指教）Single单例之前在设计模式的学习中学习了单例模式，在实际开发中，我们也将经常访问一些全局唯一的数据或者某些操作的入口都是固定的。结合C#的泛型，我们可以设计泛型单例，让其子类直接能够实现单例模式，而不是每一块单例类都需要重新定义。考虑可能会存在一些初始化的情况，因此设计一个IManage

创建型模式抽象工厂：提供一个创建一系列或相关依赖对象的接口，而无需指定具体的类建造者：将一个复杂对象的构建与表现分离，使得同样的构建过程可以穿件不同的表示。工厂方法原型...

享元模式享元模式（Flyweight Pattern）：主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它减少对象数量，从而改善所需要的对象结构的方式。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新的对象。根据实际开发经验来理解享元模式其本质就是对象缓存池。通过缓存池复用来减少动态创建对象的数量以及次数。（后续代码重构的时候会记录实际用例，这里不再介绍缓存池的实例）几种“共享”设计模式的区别原型模式：使用原型实例指定创建对象的种类，然后通过

中介者模式中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。用来降低多个对象和类之间通信复杂性。优点：降低类的复杂度，将一对多的关系转化成一对一关系。将各类之间解耦缺点：使用中介者到后期会十分庞大，变得复杂，维护难度会巨增使用场景：当系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系混乱难以复用其对象。想通过一个中间类来封装多个类的行为，而又不想生成太多子类的时候可以考虑采用中介者模式。示例利用群聊来展示中介者模式的简单使用：类结构设计如下：代码逻辑如下：

观察者模式观察者模式又叫做发布-订阅模式，定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。当这个主题对象在状态发生变化时，会通知所有的观察者对象，使它们能够自动更新自己。典型案例：游戏开发中，会有多种使用金币，展示金币的地方。当使用或获得金币后需要通知所有展示的界面刷新当前最新的金币信息。简单的观察者模式类结构图如下所示：通过GoldSubject通知改变，让所有监听者自动刷新，在游戏设计中多处界面用到相同数据时，比较适合使用观察者模式。 public abstract

建造者模式建造者模式（Builder Pattern） 使用多个简单的对象一步一步构建一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。通俗的来讲就是讲一个复杂的对象的创建，拆分为若干子过程。在一些零部件基本不发生变化，但是组合经常发生变化的时候考虑使用建造者模式使用建造者模式，独立的建造者相对独立，易于扩展，便于控制细节风险使用建造者模式，产品需要有共同点，范围使用有限制。如果内部变化复杂，会有很多建造者类列如：1、游戏玩家的装备：武器、技能、皮肤、外观模型

桥接模式桥接模式（Bridge）：官宣是用于把抽象化与实现化解耦，使得二者可以独立变化。属于结构型模式，它通过提供抽象化和实现化之间的桥接结构来实现二者的解耦。其实通俗的理解来说就是基类A包含B接口，但是B接口不属于基类A，但是通过B接口，可以扩展衍生很多不用的方法。A类和继承自A的派生类都可以很容易的通过B的接口来实现不同的功能表现。虽然Play，和Stop需要执行DoAction方法，但是将DoAction做成接口，后期扩展时只需要添加相应的DO的类就可以实现不同的功能方法。如果变化情况多，采用原

组合模式组合模式（Composite Pattern）,又称之为部分整体模式。将对象组合成树形结果以表示“部分-整体”的层次结果。组合模式使得用户对单个对象的组合对象具有一致性。当需求中国是提现部分与整体层次的结构是，以及希望用户可以忽略组合对象与单个对象的不同，统一的使用组合结构中的所有对象时，就应该考虑组合模式了。...

命令模式命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传递给调用对象。调用对象寻找可以处理改命令的合适对象，并把改命令传给相应的对象，该对象执行命令。优点：降低系统耦合度，新的命令可以很容易的添加到系统中缺点：使用命令模式可能会导致某些系统有过多的具体命令类以下是命令模式的一个简单示例： public interface ICommand { void Execute(); }

单例模式单例模式：保证一个类有且仅有一个实例，并提供一个访问它的全局点在内存中只有一个实例，减少内存的开销，尤其是频繁的创建和销毁实例避免对资源的多重占用一个类只关心内部逻辑，并不关心如何实例化 class Singleton<T> where T:new () { private static T instance; public static T Instance { get

适配器模式适配器模式（Adapter），将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容不能一起工作的那些类可以一起工作。适配器模式主要解决在软件系统中，常常要将一些现存的对象放到新的环境中，而新环境的接口是现对象不能满足的。可以让任何没有关联的类一起运行，提高复用性，灵活性好。过多的使用适配器模式会让系统非常凌乱，不易整体把握，后期维护困难。适配器模式大多用于软件开发后期，为了兼容就版本时使用适配器模式的本质就是通过为不同类添加相同的接口，来达到统一的目的。此处不做详细的

状态模式状态模式（State Pattern），类的行为是基于它的状态改变的，状态模式主要解决的是当控制一个对象的条件表达式过于复杂的情况。把状态的判断逻辑装移到表示不同的一系列类当中，可以把复杂的判断逻辑简化。状态模式的好处是将特定的状态相关的行为局部化，并且将不同状态的行为分割开来。将特定行为的状态相关都放入一个对象中，由于所有的状态相关的代码都存在于某个ConcretaState,所以通过定义新的子类可以很容易地增加新的状态和转换。通俗来讲，状态模式就是为了消除庞大的条件分支语句。当一个对象的

模板模式模板方法模式（Template Pattern）是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使用子类可以不改变一个算法的结构即可重定义该算的某些特定步骤。模板方法模式是通过把不变的行为搬移到超类，去除子类中的重复代码来提现它的优势。模板方式模式提供了一个很好的代码复用平台。在虚拟基类中定义好一系列的动作，在子类中进行实现： public abstract class MyGame { public abstract void Init();

原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。其实所谓的原型模式本质上是在勒种预留的对对象的复制接口。对于一些初始化信息发生变化不大的情况下，可以采用Clone的方式创建对象，不用每次都是重新初始化对象。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。浅拷贝在.Net中，System命名空间中提供了I

在面向对象的编程中，由于某些原因（安全控制，核心保护等），或者直接访问对象时会给使用者或系统带来很多麻烦，这时需要为对象提供一种代理来控制对该对象的访问，这种结构型模式就属于代理模式代理模式使用代理模式职责清晰，扩展性高。但是由于增加了代理对象，因此有些类型的代理模式可能会造成请求的速度变慢。部分代理实现的过程可能相对比较复杂。上图为简易的代理模式设计图，用代理类ProxyPrivilege来实际控制RootPrivilege对象，程序设计时可以将有限的接口暴露出来使用扩展，而不影响原有的RootP

设计模式（一）——工厂模式、策略模式设计模式（二）——工厂模式进阶：工厂方法模式、抽象工厂模式之前的两篇文章中学习了简单工厂模式、策略模式、工厂方法模式以及抽象工厂模式，但是这几种设计模式有一个共同特点，都属于创建型模式，创建都是有共同的接口指向创建的对象。通俗的来讲，它们都是用来处理同类型的业务逻辑。如果需要向现有的结构添加不同的新的功能，同时保证不改变其原有的结构，这就需要用到结构型模式装饰模式装饰器模式，动态的给一个对象添加一些额外的职责。就新增功能来说，装饰器模式相比子类更为灵活。主要解决通

在 面向对象设计的两大原则：单一原则：就一个类而言，应该仅有一个引起它变化的原因，单个类处理单个 功能。不要把过多的功能模块堆砌到单一的类中，那样会导致后期维护麻烦，缺乏灵活性。开放——封闭原则：在设计时类、模块、函数等应该是可以扩展，但是不能修改 将各个模块独立化，尽可能的去扩展功能而不改变原有的功能，在软件的需求发生改变时，系统可以保持相对的稳定。上一章设计模式(一)——工厂模式、策略模式中学习了两种设计模式，但是不管是工厂模式还是策略模式都有两个很明显的问题，都需要switch来选择当前使用

简单工厂模式工厂模式是最常用的设计模式之一，属于创建型设计模式。通过创建不同的子类，具体的逻辑在子类中。典型例子：实现简单的加、减、乘、除的计算上图是利用VS类设计工具绘制的UML类图，OperationFactory负责创建，OperationAdd、OperationSub、OperationMul、OperationDiv分别对应加、减、乘、除的具体计算逻辑，他们都继承自Operation基类。后期扩展需要其他运算方法时只需要添加对应的计算类然后修改OperationFactory中的创建方