QFramework框架决定版1-9

框架简要介绍

• 什么是框架？
  • 框架简单来说，就是定义一些基础方法的封装，形成一个特定的编写思路。
  • 根据开发者的需求，自定义一系列的，更为直接的方法的集合，一个框架拥有较为明确的代码编写思路，尽量将同一类型的代码集合在一起，尽量达到低耦合，高内聚的要求，类基本满足单一职责原则，开-闭原则（对扩展开放，对修改关闭）
  • 游戏也是软件，因此一个游戏的代码开发在一定程度上是有固定规律的，比如，游戏中肯定有玩家角色，NPC，玩家和NPC产生交互，玩家和地图产生交互等，其中代码逻辑是有相通的部分的，框架是将代码逻辑抽象出来形成一个整体，以此来适配同一类型的游戏开发。这里所指的类型范围可大可小，根据框架的完整度决定。
• QFramework是一个开源框架，作者是凉鞋，GitHub地址：QFramework开源框架_Github

学习要点记录

1. 重视命名空间，框架在一定程度上和直接导入Unity资源商店中的插件包类似，通过引入命名空间在该C#脚本中遵循相关使用规则。

2. 开发学习使用了Game窗口中鼠标点击物体方法，OnMouseDown（）等方法，当鼠标点击到 挂载了包含这个方法的脚本的 物体时，触发该方法。哪怕是2D场景，也应该遵循这个方法，而不是直接使用IPointer接口，因为那是关于UI的鼠标控制的接口，在实际应用中，应该将游戏场景(GameScene)和UI分离。
   

3. 在游戏开发的过程中，尽量保持场景的整洁统一，便于寻找，对于命名也要规范化，比如Button物体，简写Btn+xxx。UI和Game直接分成两大类，Canvas是画布，通常只需要一个，Panel是布局底层，当一个不同的界面出现时，通常将Panel作为父物体，保证结构清晰，即Canvas的第一级子物体，全部为Panel对象。
   

4. 配合第3点，场景分析时，使用树状结构更为清晰。比如第一个案例《点点点》的游戏流程和游戏结构如下图。
   
   

5. 根据第4点游戏结构图示，可以看到引用关系十分随机，基本上是想到什么直接引用，通过在Inspector面板中拖拽完成，这种方式很快很简单，但是当项目一复杂，那么将不容易梳理。将会出现以下三个较为明显的缺点：

   1. 难维护。由于拖拽的时候，对象之间的引用关系是随机的没有规律可循的，所以当时间久了或者比人来接手次项目时要理清其中的逻辑所花费的时间会很多。
   2. 团队难以协作。很多的拖拽操作和逻辑是在场景中操作的，并且也会记录到场景里，所以在使用 git 或者 svn 或者官方的 plastics 的时候比较难以管理，容易造成冲突。
   3. 随着项目增长，新增功能较为困难（可拓展性差）。这个原因和第一条一样，拖拽的时候，对象之间的引用关系是随机的没有规律可循的，这样会造成大量的耦合（牵一发动全身），后边当扩展功能的时候，花的时间越来越久。

6. 对象之间的交互以及模块化

   • 对象之间通常存在三种交互方式：
     • A直接调用B的方法，那么在A类中，有一个B类型的变量作为桥梁，通过该成员变量调用方法。
     • 使用委托，比如B中存在一个UnityAction类型的委托变量，那么可以在A类的Start中注册B的委托。
     • 独立事件Event，将事件从A,B两个类中独立出来，解耦，事件Event中包含三个方法，注册事件，注销事件，触发事件，事件独立出来后，便于多人协作，比如我负责A，别人负责B，那么我只要知道在哪种情况下触发事件，编写好触发的条件，不用和别人进行编写约定沟通，而别人只需要完成，这个事件发生后，B要做什么，也不管什么情况下发生的。不用沟通便能直接拼装完成功能。以下是Event事件泛型模板：
       
   • 模块化通常也分为三种：
     • 单例，比如：Manager of Managers
     • IOC ，比如：Extenject、uFrame 的 Container、StrangeIOC 的绑定等等
     • 分层，比如：MVC、三层架构、领域驱动分层等等
     • （目前还不理解）

7. 引用规则，避免双向引用，父物体调用子物体，可以直接设置子物体变量，调用方法，但是子物体想要调用父物体的方法，需要使用委托。（推荐使用委托，独立事件通常用于跨模块通信，比如UI和Game这两个不同模块的，而不是Panel和Button之间的）。同时实际项目开发中减少拖拽的引用，将引用过程写进代码中。

   • 委托使用：子物体设置委托变量，在父物体中将自己的方法注册到委托中，遵循父物体直接引用子物体的原则。
     

8. 表现和数据分离。MVC开发架构，Model，View，Controller。Model是数据模块，负责存储数据，管理数据。 可以使用数据驱动的思路。游戏流程是，Controller做出某个操作，改变的是数据（Model），数据再根据已经设定委托或者事件，改变游戏表现（View）。View -> Model 属于交互逻辑，Model -> View 属于表现逻辑。
   

9. 数据基类，将数据从一个简单的int或者float等类型变为一个类，实际数据类继承此类，泛型约束，T必须是继承IEquatable类型的，IEquatable表示可以比较，几种基础数据属性都是可以比较的，这相当于一个绑定属性，自带一个数据变化时候调用的委托，用于充当数据变量。
   

10. 命令模式，交互逻辑的优化，引入Command。将一个方法，更换为一个命令类对象，继承自ICommand接口的类，这个类只有一个方法，这样可以使得读写分离，CQRS。Command对时间和空间都进行分离，空间上将调用和方法体分离在两个文件中，时间上可以控制执行具体时间。

总结

• 本系列为学习记录，只保留关键词以及个人需要补充强化的要点。 基于凉鞋老师的QFramework开源框架，基于凉鞋老师的框架决定版课程。