gaming & coding

Pure MVC 架构简述前言游戏UI开发中，常常使用MVC架构（Model数据、View界面、Controller控制）。这个架构方便解耦数据、界面和交互逻辑。一般来说V可以持有M，C可以持有V和M。普通的MVC写法，容易把逻辑都写到C里，导致C无限制膨胀，逻辑也不好复用。Model一个界面，拥有一个Model类型的单例。这个Model是持有了多个Proxy。每个Proxy都对应了一类数据，并且提供了这访问、修改这些数据的方法。可以说Proxy是数据核心逻辑的处理地。同时Proxy可以注册一些消

单例模式优点在编译期确保一个类只有一个实例；提供一个全局访问的入口；在例子fileSystem中，甚至可以通过继承来实现不同游戏平台的逻辑封装缺点它是一个全局变量使代码晦涩、促进了耦合、对并发不友好；它必须同时解决两个问题（全局访问、一个实例）如果只想解决一个问题时，另一个功能就是枷锁；延迟初始化剥离了控制替换方案将类限定为单一实例断言...

对象池1. 使用情景当需要频繁地创建和销毁对象时；对象的大小一致时；在堆上进行对象内存分配十分缓慢或者会导致内存碎片；每个对象都封装了像数据库或者网络连接这样很昂贵又可以重用的资源，如数据库、网络的连接；2.注意点可能在闲置对象上浪费内存；同时激活的对象数量是固定的，如果超出容量有几种做法：在固定场景下调整对象池的大小，完全阻止这一点；不创建对象强行清理现存对象增加对象池的大小；如果这么做了，当这些额外空间不再被占用时，必须考虑是否恢复到原容量。每个对象的内存大小是固定

服务定位器模式这就是服务定位模式的简短介绍——它将一个服务“是什么”（具体实现类型）和“在什么地方”（我们如何得到它的实例）与需要使用这个服务的代码解耦了。依赖注入：假设你有一个类依赖另一个类。通常，这个定位器应该负责为自己构建这个实例。依赖注入却说外部代码应该扶着为这个对象注入它所需要的这个依赖实例。服务定位实现方案的选型外部代码注册优点：方便快捷、手动控制提供器如何被构建、可以在运行时更换服务提供器；缺点：定位器依赖外部代码；编译时绑定优点：速度快，所有实际工作在编译期完成；

空间分区目的与常用方法常常需要解决的问题：对象的附近存在哪些其它对象？两两比较对象的位置的蛮力算法，复杂度是O(n^2)；用链表储存同格子对象。同一个格子的对象储存在同一个链表中；遍历周围格子：每一个格子只需要遍历其 上方、左上、左侧、左下 四个格子即可；空间划分分区不依赖于对象：将空间均等地分割为若干个分区。其优点有：a. 对象可以逐步添加；b. 内存的使用量恒定。新增对象不会新增分区；c. 可以在对象可以快速移动；分区自适应于对象：二叉空间分割（BSPs）和 k-d

类型对象类型对象模式定义一个类型对象类和一个持有类型对象类。每个类型对象的实例表示一个不同的逻辑类型。每个持有类型对象类的实例引用一个描述其类型的类型对象。实例数据被存储在持有里类型对象的实例中，而所有同概念类型所共享的数据和行为被存储在类型对象中。引用同一个类型对象的对象之间能表现出“同类”的性状。如何理解：类型对象模式其实就是手动实现继承，C++中虚函数表其实就是我们的类型对象类，C++是类型对象模式在C上的应用，由编译器自动处理。使用场合当需要定意思一系列不同种类的东西，但是不希望把种

数据局部性数据局部性：现代计算机的多级缓存机制导致了一个特点；在缓存线中能使用的数据越多，程序就跑得越快。因此优化的目标就是让需要处理的数据在内存中两两相邻；CPU分支预测：当代CPU中，单条指令被处理成流水线模型，以便多条指令能并行处理。当if else等语句出现时，CPU必须进行分支预测，并在流水线中载入预测的命令。预测错误，会导致清理流水线，造成性能损耗。关键代码中避开控制流语句。优化例子：连续数组：假设有一个GameEntity数组，储存了若干实体，每一个实体有物理组件、AI组件、渲染组

脏标记模式常用做法和使用情景一组原始数据随时间变化，其衍生数据经过一些代价昂贵的操作由原始数据确定。维护一些脏标记，在原始数据被改变时，标记为脏；当需要使用衍生数据时，再计算并清除脏标记。使用情景原始数据的修改次数比衍生数据的使用次数多；递增地更新数据十分困难，因而需要脏标记来按需更新衍生数据；注意事项延时太长会有代价：当真正需要衍生数据时，可能会卡顿；必须保证每次原始数据改动时，都设置脏标记；必须在内存中保存上次的衍生数据：因为在张标记没有被设置时，是直接读取上次的衍生数据；

子类沙盒沙盒模式基类定义了一个抽象的沙箱方法和预定义的提供集合。通过将它们设置为protected的状态，以确保它们仅供子类使用。每个派生出的沙盒子类用父类提供的操作实现了沙箱方法。使用场合你有一个能派生很多子类的基类。基类可以提供子类需要的所有操作。在子类中有行为重复，你想要更容易的重用代码。你想要最小化子类和工程中其他部分的耦合。将耦合都放在了基类里，子类只和基类耦合。大类瘦身：当基类变得庞大时，可以将同模块的功能分流到辅助类或组件类中，好处是能够减少基类的函数数量，辅助类中的代码更

组件模式谈一谈继承与组合当面向对象语言第一次接触这个场景时，继承是它箱子里最闪耀的工具。 它被认为是代码无限重用之锤，编程者常常挥舞着它。 然而我们痛苦地学到，事实上它是一把重锤。 继承有它的用处，但对简单的代码重用来说太过复杂。相反，在今日软件设计的趋势是尽可能使用组件代替继承。 不是让两个类继承同一类来分享代码，而是让它们拥有同一个类的实例。使用场景组件通常在定义游戏实体的核心部分中使用，但它们在其他地方也有用。 这个模式应用在在如下情况中：有一个涉及了多个领域的类，而你想保持这些领域互相