CreatorPrimer | 组件编码心得(中)

接上次教程中的内容，讲到功能型组件与控制型组件，这里再简单回顾一下他们的要点：

1. 功能型组件：以装饰宿主节点为己任，常用的有Sprite、Labe、Widget属于这类。
2. 控制型组件：管理和控制子孙节点，比如：ScreollView、ToggleContainer，它们内部是由多个子孙点节点组合而成。

今天分享我在组件编码上一点经验，供大家参考。

1. 功能型组件设计思路

核心：以装饰宿主节点为己任

具体要怎么去做呢？我下面整理了三个要点：

1. 专注自身节点和当前组件对象自己，尽可能少的去控制其它的对象。尽可能少不是说不能控制，比如cc.LabelOutline，它需要依赖cc.Label组件控制Label的渲染；物理碰撞组件需要依赖刚体组件。
2. 谨慎设计properties属性，减少对外部组件、节点、资源的依赖，也就是说对游戏设计师无用的属性都不要暴露到属性面板上。组件暴露的接口不应该是程序员相当然的，而是对游戏内容设计相关的属性才应该暴露到属性面板上。
3. 功能型组件内部代码中杜绝对外部场景树的假设，避免出现cc.find、getChildByName等方法获取外部节点。

功能型组件一般会以纯脚本形式存在，如果做到了以上三点，我们编写的组件就可以像引擎内置的组件一样可以被随处使用了。甚至还可以跨越不同的项目，Shawn在CreatorPrimer配套代码仓库中的组件大多都是这类，供大家参考：https://github.com/ShawnZhang2015/CreatorPrimer.git

在实际项目中，不可避免的会存在有相互依赖的组件，比如：上面代码中的几个物理组件。 Shawn建议将有相互依赖的组件代码，归类存放同一路径方便管理。

功能型组件，我们提出了不少制约条件，它只能解决功能点的问题，
而不能解决，业务流程、相对复杂逻辑问题。这些问题的处理办法
我们需要使用控制型组件来完成。

2. 控制型组件设计思路

核心：管理和控制子孙节点

控制型组件，他的职责没有像功能型组件那么单纯，还需要从他们内和外两方面来进行说明。

控制型组件对内要点

控制型组件对内它管理和控制子孙节点，这是划定了他的控制的范围，不是兄弟、父级组件。其次，控制型组件管理的手段是调用子孙节点上的组件方法、属性或监听子孙节点发出的事件，尽量不参杂功能细节上的代码，这些应该交由子孙节点或组件完成。

控制型组件对外要点

内部安定好，我们看怎么面对外部，看下图：

站在更高的层次去看控制型组件，它也可以被上层控制组件所管理，从上层视角看控制型组件也是功能型组件，解决点上的问题，比如最常见的：cc.ScrollView。

控制型组件同样遵守部分功能型组件的一些规则：

1. 不要暴露内部节点和组件，也就是说，不要为了在代码中访问内部子节点或组件方便，将它们设计成properties属性，他们对游戏设计师没有任何帮助，反面形成了干扰，这里需要关注的是封装性。
2. 控制型组通常会与预制件结合形成独立的模块，并能与其它组件相互组合嵌套，形成更复杂的业务模块，以达到模块化能力。

以这种方式设计组件，尽可能为项目生产出一个个相对独立的模块，再以各个模块搭建完整的游戏。

3. 小结

本篇主要介绍了功能型组件与控制型组件的一点心得，最为主要的还是对面向对象设计原则的应用。下一次继续为大家分享，控制型组件与与预制件编辑的一些心得，欢迎关注。

---

如果觉得公众号上的文章对您或您身边的朋友有帮助，请分享给他们，愿我们一起成长！