CocosCreator组件化开发（三）：组件化

转载请保留原文链接：https://blog.csdn.net/zzx023/article/details/84849096

 

 

 

这个游戏我相信大部分的同学应该都不会陌生，N年前的爆款网游单机大作《孢子》

没玩过的其实也可以去玩一玩，非常的经典。

 

这里我就用这个游戏来开始进入组件化的讲解。

 

以这个游戏生物阶段为例，你可以看到各种各样的生物，玩家自己也可以收集DNA，改变自己的基因，让自己向着肉食动物或者草食动物发展。

 

打个比方，在游戏中会收集到翅膀这个部件的DNA以及爪子的DNA，当你在改造生物时将翅膀安装上，你的生物就可以短暂的滑翔和冲刺，战斗力和生存力方面就有有大的提升，安装爪子就可以让你的生物在近战攻击中优势更大。当我同时装备这两个部件，基本上在对战方面可以打的过大部分的怪物了。

 

大家想一想，如果是传统的开发方式，这种情况该怎么去做？

 

写一个生物的基类Base，派生一个带翅膀的子类A和一个带爪子的子类B，并且还需要有一个子类C多继承与父类A.B。

 

 

可以看到，整个继承链在实际开发中会变得很复杂，同时如果有新功能需要添加，很多事件无法分清，功能到底要放在哪一个类中。扩展起来也是非常的不方便。而且当项目进展到后期时，可能会受制于BASE类的架构，导致很多功能无法添加。

 

其实反过头来想一想，为何不用我们看到的，就像游戏中，组件的方式去写？

这样我们只需要有一个基础的生物实体、翅膀组件、利爪组件即可。

这样通过组合的方式，我们就可以轻易的组合出我们所想要的生物。同时可以看出整个代码的扩展性、代码重复利用方面有了很大的提升。

 

传统继承式开发	组件化开发
深度的继承链	低耦合
重复的逻辑代码	使用方便
复杂的多重继承	容易扩展
基类难以扩展	代码高复用

 

通过上面的粒子以及对比可以看出，组件化开发相比传统的继承式开发，有个明显的众多优势。因此不管在creator中，还是其他的一些开发环境中，使用组件化开发会让整个项目的架构更加的清晰灵活。同时也正如前面工作流所讲的，最终将组件的组合交由策划美术来完成，最大限度的发挥他们的创造力。

 

 

到这里，我感觉其实很多同学可能就问：通过前面的讲述，确实组件化开发要好很多，那是不是意味着面向对象已经不适用现在的开发了么？面向对象好难用啊。

我的答案是：

         同学，你的理解错了。

 

很重要的一点，面向对象OOP是一种编程思维，组件化是一种编程的方法论。我们通过组件化开发是以面向对象OOP为指导思想发展出来的一种编程开发方法。

 

那这里可能又有同学会问：那我们之前一直都是使用的面向对象啊？

 

在这里我要告诉大家，前面说的传统的开发方式，其实违反了很多面向对象OOP的基本原则。

 

在这里我们先回顾一下OOP需要遵守的几个基本原则：

 

单一职责原则(Simple Responsibility Principle,SRP)

如果一个类具有多个职责，应该把这多个职责分离出去，再分别创建一些类去一一完成这些职责

换句话说就是一个类的职责要单一，不能将太多的职责放在一个类中

单一职责核心：高内聚、低耦合

 

里氏替换原则(Liskov  Substitution Principle,LSP)

是继承复用的基石，说白了就是继承与派生的规则

里氏替换原则核心：在软件系统中，一个可以接受父类对象的地方必然可以接受子类对象

里氏替换原则实例：某系统需要实现画直线功能，现在有DrawLineA和DrawLineB两种画图方式，在操作类中提供了这两种画图方法选择画直线

 

依赖倒置原则（Dependence Inversion Principle,DIP）

依赖倒置也叫依赖注入、依赖倒转要针对抽象层编程，不要针对具体类编程依赖倒置原则核心：要依赖于抽象，不要依赖于具体的实现。分开来说：（注：抽象:接口或抽象类;细节:具体实现;如果把模块层次关系比作基础关系的话:高层模块和底层模块对应于父类和子类）一、高层模块不应该依赖底层模块，这两者应该依赖与其抽象 二、抽想不应该依赖细节三、细节应依赖抽象

 

接口隔离原则(Interface Segregation Principle,ISP)

使用多个专门接口来取代一个统一的接口，

一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口中。

接口隔离原则核心：不应该强迫客户端程序依赖他们 不需要的使用方法

 

迪米特原则(Law of Demeter,LOD)

又叫做最少知识原则，一个软件实体对其他实体的引用越少越好，或者说如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用，而是通过一个第三者发生间接性的交互。

迪米特原则核心：高内聚，低耦合

 

合成复用原则(Composite Reuse Principle,CRP)

在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合或通过继承。继承复用：实现简单，便于扩展。但是破坏系统的封装性。组合复用：耦合性相对较低，选择性的调用成员对象的操作。可以再运行时动态运。.合成复用核心：尽量使用对象组合而不是继承达到复用的目的

 

 

好了，复习完这些理论性的东西。我们再回过头来看。是不是我们在平常的编程过程中，实际上违反了很多面向对象的设计原则？

 

再回顾一下组件化开发。你会发现，实际通过组件化开发，能让我们更好的贯彻OOP的设计原则，从而达到更好的设计架构，更健壮的系统设计。

 

 

以上就是关于组件化开发的知识，希望大家能理解。不止于creator和cocos，组件化开发可以应用到方方面面。包括其他的引擎，以及服务器的设计都可以使用。