开发流派，到底哪种才是正途？

Creator 3.x
#326

我想问下方案1你是怎么获取需要使用的node的？想学习一下你的思路。
我的做法是根据prefab变量命名来判断是否需要使用到node，例如m_开头表示这个节点是程序需要的。然后使用封装的函数加载预制体同时自动的添加compoent组件。但是这个方法有个缺点，就是m_开头的节点名不能相同。
例如下面这样：
加载Login_IndexDlg预制体，并且自动添加Login_IndexDlgCom组件，同时继承Login_IndexDlg类。
Login_IndexDlgCom组件负责逻辑处理，Login_IndexDlg负责初始化节点（Login_IndexDlg是自动生成的）。
image
image
image

#327

就是，方案二比方案一的代码更多，算不算缺点啊，特别是做小游戏的话，资源可以远程，代码却不行，而且代码注入耗时比较大。
当然1，做app的就不用管了。
当然2，你们讨论的是方案优劣，我更看重的是应用场景。

1赞
#328

你们不如新开一个贴讨论 这个帖子已经很长了

#329

  1. 我的问题是你的组件怎么添加？编辑器/代码？而不是你说的怎么引用

    • 编辑器，那么你的方式和 A 方案一致，没必要争论

    • 代码，那么能比点击/拖动快？？

  2. 你的组件属性，比如组件属性是一个字符串或者数字。你怎么自动生成？

至于引用的问题 A 比 B 在开发时更方便，同样生成代码，B 只有运行时才知道报错，

我感觉你的回答是完全没明白我前面说的啥

#330

这个是手动拖的，用什么拖什么，拖多了也无所谓，

可以从操作上优化，只需要把节点拖到组件上，组件自动响应，list自动增加一条，要删除就叉掉，

导出那边，根据这个list，顺序导出， 比如nodeA是一个Label， 会导出一个this.nodeA_Label = this.nodeList[n]:getComponent(cc.Label)

在业务脚本那边， 就用this.ui.nodeA_Label, 这个可以导出一个模版

#331

确实也是一个思路，这样就不怕名称重复问题，不过我比较懒，懒得拖所以就用命名来自动导出脚本 :rofl:。

#332

我之前的表达意思，一直在说主体的A和B之间主要的差异， 你这理解出另一层我跟不上，没办法

这个方面，能拖动到界面里面的，那都是独立封装的，为啥要单独拿出来再导出？那直接拖进去不就行了，

但是我一般情况，都是使用默认， 除了像自动多语言的，要写入一个key，其他基本不太需要什么修改，要改尽量在代码里面持有修改， 一般情况下这种修改办法，不会影响到其他

#333

我们项目现在就有这种问题，有很多很大的预制体，里面结构一团糟。很多时候遇到一个bug，查找的时候，知道报错在xx函数，然而代码编辑器中显示这个函数的引用是0。然后就懵逼了，因为引用是其他某个加了点击事件的脚本里通过拖拽引用过来的，找那个button如同大海捞针。

#334

image

  1. 你不认为 B 比 A 慢，而我之前说的慢的原因其中之一是 组件添加/属性赋值
    你的回答：生成节点和组件的引用，和 组件添加/属性赋值 无关

  2. B 能生成的节点和组件的脚本引用代码，为什么 A 不能？这里开发速度基本可以持平所以我之前没说这里

所以你现在想说什么？？B 比 A 快吗？我觉得我已经说的很清楚了，原因都标注出来了

#335

还有组件化的精髓是 “组合” ，不要搞巨大组件，keep it simple。

再比如 有一个共用的组件 需要新加一个字段/引用， 那就加上，在代码里做下兜底，引用是空 就用 find / geChildByName 兜一下底。代码里做好注释说明

a 还有一个小优点 不要求 绑定的节点/组件 有相同的层级，有时候这种l灵活性会很方便

#336

是我理解错了

我再举个例子， 比如Label， 我是自己做一个多语言组件，继承于cc.Label，支持富文本啥的，但是会把key写在组件里面， 这个就是你说的组件添加/属性赋值了吧， 用法是A方式

但是还有一种情景，Button，我是要通过自动化脚本， 判断是button的，在auto_xxx里面，导出一行代码进行绑定，因为这样可以更好的规范button的click事件，而且click事件跟节点名称相关，找的时候也很好找，
这时候用的是B

至于其他情景，主要还是要看哪一种方便，易懂，好维护。

有一些组件很适合直接绑定在组件内，因为独立，不耦合，但是button就不一样，并不独立，因为button的回调本质还是函数，还是代码，所以在编辑器里面绑定回调，就容易引起问题，

所以我觉得，我主要还是用B

补充一下：
至于一些自定义组件，比如红点组件、特殊显示要求（圆角shader）等等， 我还是倾向用B动态添加，几个优点：
a、其他人用，直接抄这段代码，前提封装好，用A也差不多，就是对封装要求更高，因为如果需求发生更改， 不确定改动的影响大不大
b、全局检索快，IDE一搜索就出来，哪里用看下代码就行
c、封装方便，可以快速制作通用接口， 跟a点差不多
d、错误排查快，我们首先拿到的是堆栈，可以快速定位，可是用A，报错点得往回找好几个可能才看到自己写的函数

1赞
#337

很多人说a 的缺点感觉都是管路问题。
主程管理缺失，或者开发人员素质、水平良莠不齐。

  1. 协作问题，核心不在于拖不拖节点，而是场景、prefab 无法合并。总归得“加锁”，一个人改完另一个人在基础上改。
    或者 将自己修改的部分 拖成prefab，拉取到最近的场景/Prefab 再把prefab 合并上去。

  2. 升级版本 绑定节点，组件也不是核心痛点吧。引擎API废弃，资源管理大改，实现修改 才是最难的吧。

  3. 按钮回掉找不到
    这个就是项目规范的问题了。统一 onXXXBtnClick 一目了然。

b 方案相对于a 是擦屁股。
管理不善、混乱的项目用b比a强吧

#340

是啊， 没毛病，B是在一定程度上，对A做的补救，因为没有人有办法保证你的团队写的代码风格统一，每个人都有自己的特点，我觉得这个是好的，但是放到一起，你看我的代码像:poop:山，我看你的又何尝不是呢，
所以用B，做一定程度的规范

用A的，没办法保证，哪一天又有人回搞出超级节点，超级预制体，超级组件出来，到时候去修都来不及，还不如一开始就做好

#342

刚审核过的，不是新发的，我先删了

#343

GTA GTA GTA

#344

如果方案B 那么creator的意义就大打折扣了，还不如回归2dx，creator就是因为有编辑器所以才开发简单，效率高，编辑器才是他的根本意义

#345

编辑器不就是为了编辑预制体和场景比较方便吗？ 除非UE那种蓝图型的，其他引擎的框架不应该受编辑器绑定才是。

#346

我们也是降引擎，都是用引擎绑定的，研究了一下2.x跟3.x的预制体结构，写了脚本一键还原的

#347

重复率高的组件代码加载 预制体放一个脚本控制就好了 动态加载资源 自动生成路径 谁说cc.find 加载慢的 我是真的服 游戏逻辑比如物理 碰撞的 计算量比你这节点查找不知道大多少倍吧 还有每帧执行的逻辑的卡的时候就知道了 还一个个节点绑定的 我感觉这完全是新手吧 我看过比较大的手游的界面一个界面上千个节点 还不是全部放进去 你绑我看看?

#348