DevNotes_190401
数据驱动编程//MVC & MVCSE 学习与思考//Tech Designer和没有Tech的Designer
（今天Chrome丧失了文字输入能力，写一会儿字就会闪退，而且动不动时间回溯吞字）
数据驱动，是一种思想，适用的处理的目标是有一定特点的，例如操作相近而数据有别的情况，一般情况可能会switch-case或者多重if-else嵌套很多，而数据驱动就将数据和操作分离，操作相对固定而变化的是数据；
因为一定程度上，比起操作和流程，人类对于数据更敏感；
–最基础的，变化的部分与不变化的部分相隔离了；
—-提供机制，而不是策略；策略会变，而我们则需要定下机制；
MVC
对于游戏开发来说，狭义的MVC并不太适合，即使是在UI方面，比如很多时候UI的M并不是它自己用的，而是别的地方传过来的数据，V能做的显示控制又不常用，C的功能又和V有重合；
但是我们要的是这种思想
—MVCSE
分别对应 Model, View, Control, Service , EventBus
其中这个Service和MVCS的Service还不太一样，那里面的是远程通信与其数据管理，而MVCSE的远程数据管理是在Model内的；
Model是数据核心，它里面可以有很多个子Model
(那么也许Model是一个抽象层级，它里面存着各种各样concrete model，)
还区分 static 和 Dynamic的，(不轻易更改但存在load/unload，与runtime级的数据和数据逻辑)
Controller，
区分两种架构实现方式：Command / SubController
(两个架构最好仅仅二选一)
Command
生命周期断，基本不储存数据，execute操作来修改Model；
一个Controller下面有多个Command的实例，每个Command注册一个命令或事件，一旦Controller收到事件，就创建/取用某个Command，以实现其控制；
扩展：MultiCommand，组合模式，组合各Command
综合效果：每个命令都具有明确对应的Command处理逻辑；
-+：将逻辑分离，但是对于负载的多步骤逻辑、有一小些数据需要暂存的情况，或者相同命令应对不同的响应，可能会比较麻烦；逻辑分离带来的问题，既不能太细致也不能太粗放；
SubController；
长周期，注册式的EventHandler，可以储存一些数据，Controller下面多个SubController的Instance，Register或Unregister监听（很多Event/Action）。回调；
-+：动态处理，同一个操作可能会有很多SubController进行监听与处理，逻辑会变复杂；
View
View并不负责具体的显示，而是对 负责具体显示的对象 进行控制和交互，例如2d的sprite和3d SceneNode 和 UI的panel；
基本都是中介者模式来实现；
Service
是管理基础模块的组件，IO / Network / Input / Render / Physics 等，一个Service管理器带着多个Servie子模块，提供接口；
EventBus
管理事件 通信、传递、派发，其他四个MVCS所依赖的 中心 事件通信 组件；
一个EventBus带着多个 EventChannel ，负责传递不同的信息，比如Netwrok EventChannel, Timer EventChannel, Sub-system EventChannel;
实现：
一个EventChannel在内部 维持并维护 一个 事件和对应callback列表的 map，根据事件，进行相应的回调。
一般分为 直接派发（在派发事件的时候直接回调） 和 队列派发（保存至队列(也许栈也可以?)，到某一个时间点，由一个特定的线程进行事件回调），
通用的EventChannel和特殊的EventChannel，
通用的，就作为普通事件的传输管道，特殊的则通常和一个Service结合，以Service作为事件源来产生事件(Network, Timer, Input, FSM)
状态机呢？
分为 Game Flow State Machine 与 Object State Machine;
作为控制游戏主流程的状态机；MVCSE中，核心是 事件通讯，所以要用事件来做；
游戏主流程状态机的State Machine可以作为一个Service放入到Servie组件，而State应该是比较轻量的class，回调也较少(Enter , Exit)
State转换：不执行任何和状态业务香瓜你的业务逻辑，而仅仅是发出一个事件
e.g.: 向 EventChannel(“GameFlow”)发送 STATE1_ENTER
状态机接收事件 以转换状态： 由相应的Controller得到状态机的Servie，对应函数调用；
Object State Machine:
一个对象内的状态机
重量级：实现一个抽象的状态机基础框架，然后再在concrete Object 内组合一个相应的 state machine 和若干具体state;
轻量级：基础是若干个状态变量封装而成，对应状态常数、状态变量的转换条件、历史 状态变量，
=-=-=
-+：继承的问题，就是 一个地方继承了，其他的东西都要跟着继承，多了一个模块，则相应的MVC都需要多出来一个相应的；
【附联机、网络情况下的MVC架构变化】
一般 mvc 可能会带来的问题
代码冗余-多次封装，class分散
不合理滥用；
扩展：
会有 premature optimization？
会出现的情况就是 build a system, not a game;
扩展阅读，还没看：
By the way, I’ve been asking this same type of question and researching these types of design principles for some time. Here are some questions, both here and in Stack Overflow, that you might find relevant:
参见-
改改改，不熟练的没经验的就喜欢一个劲地改，项目失控简直是必然情况；SeeMe已经失控了，策划一顿暴风加内容，一大堆新元素新机制，整个架构几乎全都要大改；好嘛估计国内的有不少菜鸡策划都这个鸟样，自己对于技术一窍不通，想到什么就要什么，
这个 改 不是说不能改，策划很多情况并不知道自己的改动到底意味着什么；
量 quantitative 层面的改动并不会有什么太大问题，相对工作量和对架构的影响是较小的；但是 质 qualitative 的改动问题就会很大了；
但是 策划会不知道自己提出的到底是质变还是量变，（很有可能是缺乏编程思想和逻辑能力的体现），而是会觉得改动的大小是由自己写的策划案的字数多少反应出来的；封装好的、技术框架确定的、抽象层次和继承关系确定的情况，要加一个新模块——哦豁，完蛋；
只有两条支线而已，对话分支也只有几个；
——经典赏析：
两条支线也是支线，软件开发不是说这个功能实现的量小，就可以在做这个功能的时候减少很多工作量，既然有就一定要做整套系统，四个元素就要写搜索算法，四百个元素同样还是要搜索算法，不是说你需要处理的数很少就不用写算法了。同样的，就比如说对话分支，你没有分支那就是简单对话，但你要有分支，哪怕就三个分支，那这分支是不是产生后续影响了？是不是原来没有分支的对话系统就要重写了？又因为之前没有分支，那对话系统是不是就又和别的系统之间产生影响产生耦合了，新的耦合新的业务需求新的架构需求；那这个对话分支到底是三条还是三十条就都无所谓了，不是说只有三个分支就可以避免做这个架构了。
–就想起猴与花果山大佬的文章（之前的DevNotes有笔记），策划就给你说要刷怪，没了，就刷怪；
那程序对于这个需求当然只会做一个简单的刷怪，对着打好点的position组来选定并刷怪，没了，完全符合要求；
结果策划跑来说我们要根据时间刷怪，根据天气刷怪；
这当然就要全部重写了，
策划还会狡辩，时间不就分个白天和晚上吗，这才两种情况，天气就分个下雨和不下雨，也不就两种情况，多简单，没什么新需求
是哦没什么新需求，白天和晚上是不是就需要和时间系统产生耦合了，万一这个时间系统还会变呢，比如玩家改变了时间？下雨和不下雨是只有两个，万一你这后面又来个雾天雪天呢，是不是天气系统又有耦合了？
如果这个时候，那个原始的刷怪系统上面已经有了很多很多功能、层层封装了，很多其他系统产生了一些耦合和联系，配置文件的标准也都订好甚至已经有一些配置文件了呢。
白 写 了
而且策划一定会毁约，说不会有新的条件就等于一定还会有新的条件，有白天和晚上就一定会有上午下午黄昏黎明(当然还有些时候确实不会，但是会有更惊喜的情况，比如要一个比晚上早一会儿但又不是普通的白天的那个时间)，这就导致了我之前（可能很多情况大多数人都会这么做）想着用个别的条件来额外判断（if-else组喽，比如if白天else，is白天是个bool property之类的），但是策划一定会给你惊喜把这种情况变成2^n种不同情况的；就像搜索算法的例子一样，之前处理两个元素，只需要比较就行了，策划突然说要加一个元素“不就只加了一个元素嘛又没什么大变化”，但是比较的做法已经和别的地方产生耦合嵌套封装了，不方便随意改动，于是我们比较三个元素ifelse嵌了三层，这还算能接受，结果又过了一阵他说要5个元素了，那么ifelse还嵌五层吗；
而且策划是丝毫不觉得这有什么，因为这种情况就会自然产生类似于“我也没加什么新需求啊怎么就不行了”的想法；
（简直了点菜了人家做了一半才说不要辣椒，还会觉得不就这么一点点需求吗除了辣椒葱姜蒜还都在怎么就不行了，但是之前的辣椒已经产生影响了(耦合与关联)，这还能去掉吗？只能推翻重做）
(这里面猴与花果山大佬举例的策划案都比半月滇写的好，虽然都是让你猜他们到底想干啥和摆明了一副 这个看上去就是这么简单但是肯定有一大大大大大堆隐藏需求没给你说而且我现在就不给你说你问我我就无可奉告一定要等到开发到了一定程度才说不是我没想起来是我觉得那些都不是什么难做的不就改一点点元素增加了一点点东西嘛 的样子)
“”负责需求的人不一定需要懂程序。但是负责设计的人必须懂业务“”
很有道理，需求是具体的，设计是抽象的，抽象层次缺失或者不合理是致命的；