【步兵 经验篇】组件模式的特点

【步兵 经验篇】组件模式的特点 by EOS.

组件模式对u3d的开发者可能并不陌生，因为其框架设计大量的使用了这种模式，
但是cocos却没有使用，不过后来出的js也开始套用这种模式，他能被效仿，自然有他的优势，
接下来就总结一下，我对组件模式的一些了解。

---

高复用性

提到组件模式，我觉得他遵循了“组合”优于“继承”的设计准则，接下来我们就举个例子。
假设有现在有跑车、汽车和坦克，可能会有人这样设计：

car <- 坦克
    <- 装甲车
    <- 跑车

跑车是不具备战斗功能的，如果把战斗功能写在car中，可以实现，以后再加入潜水呢，入地呢？
无疑会导致冗余继承，而且可能会因为自己所不具备的功能引发各种各样的bug
所以这样设计更合理些，car只保留基础的功能。

car <- 战斗car    <- 坦克
                 <- 装甲车
    <- 跑车

如果又出现了潜水的车呢，可能会是这样的。

car <- 潜水car    <- 潜水车

    <- 战斗car    <- 坦克
                 <- 装甲车
    <- 跑车

但是又出现了新的 战斗潜水坦克呢？当然可以写一个潜水战斗car然后把相应的功能考过来。
但是这样重复的东西，我们明明实现了，却无法复用，无疑让人格外的不爽。怎么办呢？
这时又要转移仇恨，说为什么要出什么战斗潜水车啊，有病啊！@#*!#@#￥，来发泄自己的情绪。

如果使用了组件模式，就可以很好的解决此类问题。组件模式中，car就一个变成了容器，
等着你来给他添加各种功能，想要什么模块，塞进去，他就可以是跑车、可以是坦克、也可以是潜水坦克。

---

运行时：即插即拔

比如现在有一个跑道，上边有N个buff，触碰后会加个闪光、加个幻影、变个造型、体积变小什么的。
如果把这些所有的效果都写到一个类中，然后openEffect(xxx)开启种种效果的话，无疑这样会导致你的类变的十分庞大。
而且加新需求，你就要继续塞进你的类中，到最后会导致他变成一个庞然大物，难以维护。
而且如果有N个类继承了它，无疑每次修改这个类都存在非常大的风险，通常我们不会去修改一个非常稳定的模块，
因为每次修改为了保证它没有问题，都需要进行大量的测试，与其相关甚至不相关的模块，都要测试才能确定。
因为你不能确定，它不会出现因为数据的共享而引发的bug。就像开发过程中，永远要备份一个的稳定版，
遇到查不出的bug或来不及补完的功能或其他紧急情况也能保证上线，稳定是必须的。

组件模式用组件模式也能得到很好的解决，可以给一个buff组件列表，
触碰buff加进来，每个组件负责自己的逻辑，到时间再把自己移除掉。

---

低耦合性

理想的状况是，我只负责自己的模块，确保自己没有问题后，只提供接口给你调用，那么这个模块就是稳定的。
但是实际开发中是不存在的，组件就是提供给使用者的，必然和使用者之间产生关联性，也就是耦合性。
举个反例，也就是高耦合。比如有一个流程A->B->C->D，最恶心的方案是A中引用B，B中引用C，C中引用D。
当B被取消时候，A又要重新引用C，BD调换顺序时候，ABC都后改动，真是牵一发而动全身。
如果最后再加个D反馈给A，那就更加不堪设想。~
但是我们明明就可以用一个很简单的循环来处理，你就会说了谁会这么傻，可能如此简明的问题你不会。
但当问题被复杂话，又或者一开始只有A然后BCD是渐渐的加入的，很可能为了意识方便，就那么间的
用了一个“简单的处理办法”，渐渐的，就很可能就会被引导成前面所说的情况，正所谓“当局者迷”。

而组件模式能从根本上组织这种问题的发生，因为它只负责自己的部分，不会引进组件到自身。
其实这也是功能模块化，所具备的基本特点。

---

易测试性

合理划分组件，可以让组件相对功能单一，那么相对复杂的功能出错的概率会变小，测试它也将变得更简单。
比如它和使用者只产生一些数据耦合，那么只要使用者具备着这样数据就可以使用，成为组件使用者。
举例：比如我们是为一个坦克写的一个移动组件，使用到了，他的坐标(x,y,z)。
那么我们完全可以使用一个具备(x,y,z)属性的小球，来进行测试，不必去理会坦克其复杂的结构。
通过测试确定没问题，那么之后该模块引发报错的概率将很低。

功能越单一，出错的概率也就越小，反推写一个几百行的函数，出错的概率更大，
所以应该善于把函数简单化、短小化，最好是一屏之内，阅读起来也很舒服。

---

改动代价小

程序最恨的是什么？或许就是”特殊处理“，往往给你一个需求，你想出很好的方案。
但当需求不断变化的时候，由于经验不足或者疏忽，没有预留一些可拓展的接口，
你就需要做各种各样的”特殊处理“，然后就这样不停的破坏你的结构，你的流程，
原本清晰的分支、结构变成一丢乱麻，到最后可能自己都不想去看。

因为组件有功能单一，耦合性低的特点，所以修改起来，对其他模块影响很小。
可以较省心的做一些改动，另外之前也说过，我们是不愿意去修改以稳定的东西的。
所以当需要改动太的太多或者之前有很多地方使用且很稳定，那么我们可能就需要重新。
就算如此写一个组件所花费的代价也远远小于重新写一个具有相同功能的类或一套流程。

---

总结

组件模式其模块化的特点，才颇受游戏引擎的架构师们的喜爱，模块间交集越少，越独立，
相对所需的付出也就越少，也不需要一人包揽多个模块，节省更多的精力在自己的模块上。
游戏需求的频繁多变，相应功能的变化多端，以及与其相对于的快节奏开发，
或许正是组件模式开发，备受游戏开发者们喜爱的原因=、=
(ps：推荐一首歌《一人我编程累》~ 啧啧，那个词~稳得很！)

See Again~
之前
真爱无价，欢迎打赏~