Unity客户端架构设计心得
移动游戏开发的历史及现状 国内的游戏市场，在12年以前还是以PC为主，主要有以下原因： 基础设施跟不上，都是2G，3G。2013年年底才正式发放4G网络。 移动设备性能不高，多数还是以打电话为主。而且 …
设计模式
搬砖方法论：分层策略
前言：当编写系统模块时，都会注意高内聚、低耦合、单一等等原则，虽然这些原则并非强制性，但是它对后续扩展有很好的指导性建议。但这些仅仅是微观上的，在宏观上也是需要类似这种指导性建议。这也是我们需要对架构 …
搬砖方法论：保持整洁架构的常用准则
软件的首要技术使命：管理复杂度。— 史蒂夫·迈克康奈尔《代码打全（第2版）》 SOLID原则 搬砖方法论：Single Responsibility Principle(单一职责原则、SR …
设计模式之面向对象七大原则
1. 单一职责原则（Single Responsibility Principle） 2. 里氏替换原则（Liskov Substitution Principle） 3. 依赖倒置原则（Depend …
3-11设计模式之解释器模式（Interpreter）
3.11.1 模式意图: 在系统会有一些需要进行转换的字符或句子，通常会使用正则表达式，但正则表达式使用起来相对复杂，如果我们需要转换的句子较少、简单，可以使用解释器模式来完成转换的需求。 3.11. …
3-10设计模式之模板方法模式（Template-Method）
3.10.1 模式意图: 在系统有一些按照指定步骤执行的操作，这时如果将对应步骤的操作细节写在一起，势必会造成耦合度增加 ，不利于扩展，这时可以使用模板方法模式，抽象其中的顺序步骤，将具体的操作细节留 …
3-9设计模式之访问者模式（Visitor）
3.9.1 模式意图: 当我们已经含有固定的数据结构，但需要频繁的更改对数据操作的方式，如果将数据与行为放在一起，会影响数据所在对象结构的稳定性，增加操作的风险，这时可以使用访问者模式，使数据与操作行 …
3-8设计模式之观察者模式（Observer）
3.8.1 模式意图: 在系统中会有一些订阅发布性质的子系统，例如消息系统，用户订阅自己关注的消息，当关注的消息发出时，订阅者也会随之收到相应的推送通知。这也和生活中关注的频道相似，当频道更新时，总会 …
3-7设计模式之策略模式（Strategy）
3.7.1 模式意图: 如果在系统中需要为某一行为提供多种方案，例如不同的折扣方式；货币不同的汇率；到达某地不同的路线等情况，就可以使用策略模式。 3.7.2 模式概念: 它属于行为型模式，指对象有某 …
3-6设计模式之备忘录模式（Memento）
3.6.1 模式意图: 可以保存某个对象在一个或多个时段的状态，不破坏其对象的封装性，方便以后对其恢复（类似版本控制器），如果遇到以上需求，可以使用备忘录模式。 3.6.2 模式概念: 它属于行为型模 …
3-5设计模式之中介者模式（Mediator）
3.5.1 模式意图: 在系统中，会存在多对象间交叉连接的情况，为了减少对象间的直接引用，满足迪米特法则，可以使用一个中介层来代替原有多对象间的直接相互引用，使原来的多个对象所关联的其他对象保持最少。 …
3-4设计模式之迭代器模式
3.4.1 模式意图: 系统中会有对集合的元素进行自增或者自减顺序的访问操作，对于这种需求我们可以使用迭代器模式来建立对应的迭代器，C#自带的IEnumerator也是利用了这种模式的特点。 3.4. …
3-3设计模式之命令模式（Command）
3.3.1 模式意图: 在开发中会遇到多个技能排序释放；事件到达一定阈值时触发；对操作进行"记录、撤销、重做"等行为。在以上情况下，需要将"行为请求者"与&qu …
3-2设计模式之状态模式（State）
3.2.1 模式意图: 根据对象内部状态的不同，而产生的不同行为，常规会直接采用if else语句，但是随着状态的增多，常规方式多会造成系统耦合度的增加，bug出现几率升高，当遇到这类情况时，可以使用 …
3-1设计模式之责任链模式（Chain-of-Responsibility）
3.1.1 模式意图: 在系统中，同一个元素可能有多个对象根据优先级对其进行逐步处理，并通过返回处理的状态判断（Ture、False、Null等）是否交由下一对象操作，一般情况下我们会使用if els …
2-7设计模式之外观模式（Facade）
2.7.1 模式意图: 系统中常含有多个子系统，随着子系统不断增多，如果始终保持对子系统的直接调用，会明显提高业务逻辑和子系统间的耦合度，造成系统混乱，加大阅读困难，这时我们可以使用外观模式，用此模式 …
2-6设计模式之代理模式（Proxy）
2.6.1 模式意图: 在系统中有时需要对某对象创建时机进行约束；内容添加过滤行为；对象间接引用，想满足以上种种情况，但又不想破坏其原有功能结构，这时可以使用代理模式以替身方式来达到目的。 2.6.2 …
2-5设计模式之享元模式（Flyweight）
2.5.1 模式意图: 在系统中会有一些反复使用的元素，这些元素一般使用周期较短，但使用频率高，为了达到提高复用性和节省内存的目的，则可以使用享元模式。 2.5.2 模式概念: 它属于结构型模式，运用 …
2-4设计模式之组合模式（Composite）
2.4.1 模式意图: 在处理树形结构数据时，通常必须区分叶节点和分支节点。这使代码更复杂，也更容易出错。组合模式模糊了叶节点和分支节点的概念，可以使叶节点和分支节点以单一对象的方式统一处理，且所有节 …
2-3设计模式之装饰器模式（Decorator）
2.3.1 模式意图: 不需要额外创建子类的情况下，动态的为对象添加功能，并且不会更改类对应的结构。 2.3.2 模式概念: 它属于结构型模式。动态地给一个对象添加一些额外的职责，就增加功能来说，装饰 …
2-2设计模式之桥接模式（Bridge）
2.2.1 模式意图: 在实际开发中，如果仅仅关注对象间的协作，随着系统的不断壮大，对象之间的耦合度会逐渐增大，维护成本也会随之增高。所以我们要从关注对象间的协作，转变为关注它们间的关系、及其组成模型 …
2-1设计模式之适配器模式（Adapter）
2.1.1 模式意图: 当需要将现有的接口转化为目的期望的接口，且保持功能不变，这时运用适配器模式就可以完成转化。 2.1.2 模式概念: 属于结构型模式，将一个类的接口转换成用户期望的另外一个接口。 …
1-6设计模式之单例模式（Singleton）
1.6.1 模式意图: 对于游戏中的某些类来说，只有一个实例很重要，例如各种Manager管理类，在系统中多处可调用，且始终保持独一无二的特性，可以使用设计模式中的单例模式来完成这类任务。 1.6.2 …
1-5设计模式之建造者模式（Builder）
1.5.1 模式意图: 当面临一个复杂对象的创建时，通常由各个子对象按照一定的顺序组合而成；随着需求的不断变化，复杂对象对应的各个子对象也随之变化，但组合顺序相对稳定。我们需要将一个复杂的构建与其表示 …
1-4设计模式之原型模式（Prototype）
1.4.1 模式意图: 当实际开发中，需要在 运行期间 通过 已创建的实例，复制和自身一模一样(也可定制)的对象（类似于细胞分裂）。对于这种需求可以使用“原型模式”解决。 1.4.2 模式概念: 此模 …
1-3设计模式之抽象工厂（Abstract-Factory）
1.3.1 模式意图: 如果业务需求创建一系列相同产品簇中的产品，可能会产生创建分支过多，创建产品遗漏等风险。这时使用抽象工厂可以有效避免上述问题，并提高其封装性，从概念上更符合单一原则。 产品簇（P …
1-2设计模式之工厂方法（Factory-Method）
1.2.1 模式意图: 当一个工厂统一负责所有产品的创建时，势必造成代码维护成本过高，但用一个工厂对应一类产品，使其创建过程一 一对应，可以更细粒度的控制产品的创建。 1.2.2 模式概念: 工厂方法 …
1-1设计模式之简单工厂（Simple-Factory）
1.1.1 模式意图： 如果将实例化产品（product）的方式与使用行为放在一起，势必会造成功能职责划分混乱、代码阅读困难、出现bug难以查找。这时采用简单工厂模式就可以最大限度避免上述问题。 1. …