feat: merge to 再看设计原则.md

Author: yyc-git

packages/ECS模式/article.md

@@ -1,15 +1,15 @@
-[TOC]
-
 # 普通英雄和超级英雄
 
 ## 需求
 
 
 我们需要开发一个游戏，游戏中有两种人物：普通英雄和超级英雄，他们具有下面的行为：
+
 - 普通英雄只能移动
 - 超级英雄不仅能够移动，还能飞行
 
 我们使用下面的方法来渲染：
+
 - 使用Instance技术来一次性批量渲染所有的普通英雄
 - 一个一个地渲染每个超级英雄
 
@@ -49,18 +49,22 @@ World是游戏世界，由多个普通英雄和多个超级英雄组成。World
 
 首先，我们看下Client的代码；
 然后，我们依次看下Client代码中前两个步骤的代码，它们包括：
+
 - 创建WorldState的代码
 - 创建场景的代码
 
 然后，因为创建场景时操作了普通英雄和超级英雄，所以我们看下它们的代码，它们包括：
+
 - 普通英雄移动的代码
 - 超级英雄移动和飞行的代码
 
 然后，我们依次看下Client代码中剩余的两个步骤的代码，它们包括：
+
 - 初始化的代码
 - 主循环的代码
 
 然后，我们看下主循环的一帧中每个步骤的代码，它们包括：
+
 - 主循环中更新的代码
 - 主循环中渲染的代码
 
@@ -333,6 +337,7 @@ OneByOne渲染 SuperHero...
 5.打印了WorldState
 
 我们看下打印的WorldState：
+
 - WorldState的normalHeroes中一共有两个普通英雄的数据，其中有一个普通英雄数据的position为[2,2,2]而不是初始的[0,0,0]，说明该普通英雄进行了移动操作；
 - WorldState的superHeroes中一共有两个超级英雄的数据，其中有一个超级英雄数据的position为[6,6,6]，说明该超级英雄进行了移动和飞行操作
 
@@ -405,17 +410,21 @@ World是游戏世界，由多个GameObject组成。World负责管理所有的Gam
 
 首先，我们看下Client的代码；
 然后，我们依次看下Client代码中前两个步骤的代码，它们包括：
+
 - 创建WorldState的代码
 - 创建场景的代码
 
 然后，因为创建场景时操作了普通英雄和超级英雄，所以我们看下它们的代码，它们包括：
+
 - 移动的相关代码
 - 飞行的相关代码
 
 然后，我们依次看下Client代码中剩余的两个步骤的代码，它们包括：
+
 - 初始化和主循环的代码
 
 然后，我们看下主循环的一帧中每个步骤的代码，它们包括：
+
 - 主循环中更新的代码
 - 主循环中渲染的代码
 
@@ -791,11 +800,13 @@ OneByOne渲染 SuperHero...
 
 通过打印的数据，可以看到运行的步骤与之前一样
 不同之处在于：
+
 - 更新4个英雄现在变为更新4个positionComponent
 - 打印的WorldState不一样
 
 
 我们看下打印的WorldState：
+
 - WorldState的gameObjects包括了4个gameObject的数据，其中有一个gameObject数据的positionComponent的position为[2,2,2]，说明它进行了移动操作；
 - 有一个gameObject数据的positionComponent的position为[6,6,6]，说明它进行了移动和飞行操作
 
@@ -859,6 +870,7 @@ GameObject不再有数据和逻辑了，而只是一个全局唯一的id。组
 
 
 - 增加System这一层，来实现行为的逻辑
+
 一个System实现一个行为，比如这一层中的MoveSystem、FlySystem分别实现了移动和飞行的行为逻辑
 
 
@@ -867,6 +879,7 @@ GameObject不再有数据和逻辑了，而只是一个全局唯一的id。组
 
 
 值得注意的是：
+
 - GameObject和组件的数据被移到了Manager中，逻辑则被移到了Manager和System中。其中只操作自己数据的逻辑（如getPosition、setPosition）被移到了Manager中，其它逻辑（通常为行为逻辑，需要操作多种组件）被移到了System中
 - 一种组件的Manager只对该种组件进行操作，而一个System可以对多种组件进行操作
 
@@ -890,6 +903,7 @@ World是游戏世界，虽然仍然实现了初始化和主循环的逻辑，不
 
 我们看下System这一层：
 有多个System，每个System实现一个行为逻辑。每个System的职责如下：
+
 - CreateStateSystem实现创建WorldState的逻辑，创建的WorldState包括了所有的Manager的state数据；
 - UpdateSystem实现更新所有人物的position的逻辑，具体是更新所有PositionComponent的position；
 - MoveSystem实现一个人物的移动的逻辑，具体是根据挂载到该人物gameObject上的一个positionComponent和一个velocityComponent，更新该positionComponent的position；
@@ -974,21 +988,26 @@ Manager层：
 
 首先，我们看下Client的代码；
 然后，我们看下Client代码中第一步的代码：
+
 - 创建WorldState的代码
 
 然后，因为创建WorldState时会创建Data Oriented组件的Manager的state，其中的关健是创建各自的ArrayBuffer，所以我们看下创建它的代码
 
 然后，我们看下Client代码中第二步的代码：
+
 - 创建场景的代码
 
 然后，因为创建场景时操作了普通英雄和超级英雄，所以我们看下它们的代码，它们包括：
+
 - 移动的相关代码
 - 飞行的相关代码
 
 然后，我们依次看下Client代码中剩余的两个步骤的代码，它们包括：
+
 - 初始化和主循环的代码
 
 然后，我们看下主循环的一帧中每个步骤的代码，它们包括：
+
 - 主循环中更新的代码
 - 主循环中渲染的代码
 
@@ -1047,6 +1066,7 @@ export type state = {
 ```
 
 这是PositionComponentManager的state的类型定义，它的字段解释如下：
+
 - buffer字段保存了一个ArrayBuffer，它用来保存所有的positionComponent的数据。目前每个positionComponent的数据只有position，它的类型是三个float
 - positions字段保存了ArrayBuffer的一个视图，通过它可以读写所有的positionComponent的position
 - maxIndex字段是ArrayBuffer上最大的索引值，用于在创建一个positionComponent时生成它的index值
@@ -1468,6 +1488,7 @@ OneByOne渲染 SuperHero...
 
 
 我们看下打印的WorldState：
+
 - WorldState的gameObjectManagetState的maxUID为4，说明创建了4个gameObject；
 - WorldState的positionComponentManagerState的maxIndex为4，说明创建了4个positionComponent；
 - WorldState的positionComponentManagerState的positions有3个连续的值是2、2、2，说明有一个positionComponent组件进行了移动操作；有另外3个连续的值是6、6、6，说明有另外一个positionComponent组件进行了移动操作和飞行操作；
@@ -1624,15 +1645,18 @@ Component+GameObject层：
 首先，我们看下属于用户的抽象代码
 然后，我们看下World的抽象代码
 然后，我们看下System层的抽象代码，它们包括：
+
 - CreateStateSystem的抽象代码
 - OtherSystem的抽象代码
 
 然后，我们看下Manager层的抽象代码，它们包括：
+
 - GameObjectManager的抽象代码
 - DataOrientedComponentManager的抽象代码
 - OtherComponentManager的抽象代码
 
 最后，我们看下Component+GameObject层的抽象代码，它们包括：
+
 - GameObject的抽象代码
 - DataOrientedComponent的抽象代码
 - OtherComponent的抽象代码

packages/依赖隔离模式/article.md

@@ -1,4 +1,4 @@
-[TOC]
+
 
 # 编辑器使用引擎创建场景
 
@@ -33,6 +33,7 @@ Three.js是Three.js引擎
 
 
 我们依次看下每个模块的代码，它们包括：
+
 - Client的代码
 - Editor的代码
 
@@ -184,6 +185,7 @@ Client通过依赖注入的方式注入Engine接口的一个实现（BabylonImpl
 ## 给出代码
 
 我们依次看下各个部分的代码，它们包括：
+
 - 用户的代码
 - 编辑器的代码
 - 容器的代码
@@ -325,6 +327,7 @@ BabylonImplement的implement函数使用了Babylon.js引擎，返回了Engine接
 <!-- ，从而消除了外部依赖带来了副作用 -->
 
 哪些依赖属于外部依赖呢？依赖的各种第三方库、外部环境等都属于外部依赖。具体来说：
+
 - 对于编辑器而言，引擎、UI组件库（如Ant Design）、后端、文件操作、日志等都属于外部依赖；
 - 对于引擎而言，各种子引擎（如物理引擎、动画引擎、粒子引擎）、后端、文件操作、日志等都属于外部依赖
 
@@ -398,6 +401,7 @@ BabylonImplement的implement函数使用了Babylon.js引擎，返回了Engine接
 
 
 我们依次看下各个部分的抽象代码，它们包括：
+
 - 用户的抽象代码
 - 系统的抽象代码
 - 容器的抽象代码
@@ -495,6 +499,7 @@ export let api1 = function () {
 
 
 依赖隔离模式主要遵循下面的设计原则：
+
 - 依赖倒置原则
 系统依赖于外部依赖的抽象（Dependency）而不是外部依赖的细节（DependencyImplement和DependencyLibrary），从而外部依赖的细节的变化不会影响系统
 - 开闭原则
@@ -578,6 +583,7 @@ export let api1 = function () {
 洋葱架构与传统的三层架构的区别是颠倒了层之间的依赖关系：洋葱架构将三层架构中的最下层（外部依赖层）改为最上层；将三层架构中的倒数第二层（领域模型层）下降为最下层
 
 洋葱架构的核心思想就是：
+
 - 将变化最频繁的外部依赖放在最上层从而不影响其它层
 - 将领域模型放在最下层，使其不受其它层的影响。虽然它的变化会影响其它层，但是它通常比较稳定，不容易变化
 
@@ -633,18 +639,21 @@ export let api1 = function () {
 
 我遇到过这种问题：3D应用开发完成后，交给3个外部用户使用。用了一段时间后，这3个用户提出了不同的修改外部依赖的要求：第一个用户想要升级3D应用依赖的引擎A，第二个用户想要替换引擎A为引擎B，第三个用户想要同时使用引擎B和升级后的引擎A。
 如果3D应用没有使用依赖隔离模式，而是使用调用引擎这个外部依赖的话，我们就需要将交付的代码修改为3个版本，分别满足3个用户的需求。交付的3个版本的代码如下：
+
 - 使用了升级A的3D应用代码
 - 使用了B的3D应用代码
 - 使用了B和升级A的3D应用代码
 
 因为每个版本都需要修改3D应用中与引擎相关的代码，所以导致工作量很大。如果使用了依赖隔离模式进行解耦，那么就只需要对3D应用做下面的修改：
+
 - 修改AImplement和ALibrary，实现升级
 - 增加BLibrary
 - 增加BImplement，它使用BLibrary
 - 增加ABImplement，它使用BLibrary和升级后的ALibrary
 - DependencyContainer增加保存B、AB的闭包变量和对应的get、set函数
 
 这样的话，交付的代码就只有1个版本，从而减少了很多工作量。只是该版本的代码需要在Client中分别为这3个用户注入不同的DependencyImplement，具体如下：
+
 - Client为第一个用户注入升级后的AImplement
 - Client为第二个用户注入BImplement
 - Client为第三个用户注入ABImplement

packages/再看设计原则/依赖倒置原则/article.md

@@ -17,6 +17,7 @@
 依赖倒置原则具体是指模块或者函数之间不应该直接依赖，而应该是依赖于它们的接口或者类型。所以说，符合依赖倒置原则的编程可以看作是“面向接口/类型编程”
 
 符合依赖倒置原则有下面的好处：
+
 - 减少细节之间的耦合性
 - 便于替换细节
 - 提高系统的稳定性