扩展代码说明
---

# 为什么会有这个目录

本项目本身是一个对 Cesium 项目的 fork, 需要同时做好两项基本工作.

1. 基于 cesium 源代码实现多种定制化基础功能
2. 及时且高效的从 cesium 新版本源代码拉取合并新特性

为了实现 #1, 我们不可避免的需要对 cesium fork 版本的代码做出改动, 为了简单合并未来 cesium 的变更, 我们需要将 cesium 源代码中的改动控制到最小.

我们尽可能的, 以`可选插件`的方式注入我们的代码. 比如参考火星科技所做的, 新增一个`ExpandByMars.js`文件.

例如之前我们提到的实现地形渲染次序跳转的代码修改, 当时我们将

> GlobeSurfaceTileProvider.js
```js
command.pass = Pass.GLOBE;
```
改为了
```js
command.pass = Pass.TRANSLUCENT;
```

这是一种侵入式的修改, 永久性改变了 cesium 的默认行为. 火星科技做得更好, 它们是这么改的

> GlobeSurfaceTileProvider.js
```js
command.pass = Pass.GLOBE;
```
改为
```js
command.pass = M.underEarth.enable?Pass.TRANSLUCENT:Pass.GLOBE;
```

还有
> RenderState.js
```js
var enabled = cull.enabled;
```
改为
```js
var enabled = defaultValue(M.undMerEarth.cullFace, cull.enabled);
```

注意这个 M, 即火星的扩展功能包. 扩展功能和想要的状态控制都在扩展包中实现.

# 该目录的职责

实现一个桩对象, 负责桥接扩展包和本工程中被修改过的 cesium 代码.

注意: __扩展包本身不在本项目中编写, 会单独开设一个项目.__

该扩展包的项目名称为 `@msign/vigna`

# 关于反向注入

我们假设一个场景, 有一个`项目A`需要使用到三维功能.

直接的思路是 `项目A` 引用指定版本的 `angularis`, `angularis` 再依赖某个特定版的 `vigna`. 这会带来一个问题 ---- `项目A` 对 `angularis` 的特定版本产生了强依赖. 这不符合设计预期, 我们的设计通过在扩展包`vigna`建立一套扁平化的面向业务的接口, 屏蔽掉 cesium 自身的一些复杂接口. 尽可能让业务层代码可以完全不用理会 cesium 自身的接口.

于是我们考虑, `项目A` 导入 `vigna`, 而非 `angularis`. 虽然从代码逻辑上来看似乎是 `angularis` 在依赖 `vigna` 中提供的扩展功包功能.

由 `vigna` 来选择自己依赖某个版本的 `angularis`, 并通过本目录下实现的桥接功能, 在运行时注入对象.



