重构客户端RoomScene模块的思考

-----20240103-----

现在做了游戏服务器后，对于多态和接口的理解肯定是更加深入了，像之前写客户端时，其实已经有了重构的想法，如今看来，其实主要是：写脚本这种语言不利于抽象思维，java这种比较适合抽象思维，虽然说：抽象有时用不好，但是确实是一个较好的解决办法(也可能是唯一)。

1.避免if else，这种就是：根据type + 接口去实现无感知的调用。

游戏中有可能是不同的房间，那么我们通过重写方法去实现覆盖之类的。

2.全局变量

其实我们也不是说不能一个TableData下来，只不过里面可能是有一些冗余字段，但是，我们也是像上面一样通过接口 + 继承 + 转换去实现也不是不可以。 这样子没有什么冗余数据。

3.程序块的组织

之所以当时写的不好，其实还是因为没有抽象思维，而且我们最好保持：单一原则，一个类尽量只干一件事，不行我们可以通过继承去扩展，而不是简单的通过 ------- 去实现代码隔离开，这样子一个类会特别长。 

--------------------------------------------------

1.函数名字的命名

initXXX   ->只调用一次
比如：设置当前的玩法，那么在这个里面调用一次即可，不应该又在这里调用，又在其它的里面调用，很容易出错

updateXXX ->调用多次
比如：人数的刷新，可能过段时间就调用一次，因此不要起一个init方法
 

2.当前是什么玩法,玩法处于哪个阶段。一个模块只能干一件事情。避免写大量的if else，看看能否可采用配置的形式去实现

if playType == XXX then
if stage == XXX then
...
elseif stage == XXX then
...
end
elseif playType == XXX then
...
end

然后，要根据当前是什么玩法，及其什么阶段，来显示界面。
 

3.全局变量的处理

写成service方法,不要用gt.playerData这种类似的写法，个人觉得不好.到底在service中处理gt.var 还是封装到runningScene.var
还是写到XXXService中的一个成员呢？ 最好这个变量使用前起码初始化过一次，写gt中也是可以的。
比如托管状态，比如金币的一些信息：补助日期了，之类的
 

4.有些消息可能在界面中才发，也有可能在别的界面时，已经发了，消息注册到CommonMessage中即可

这时候可以先拿着XXXService存储下当前的状态，然后: 
1.enter时处理一下，代表在别的界面已经发了;
2.在processEvent时处理一下，代表在本次这个界面中发了.

5.最好还是想清楚了再写代码

然而有时候确实想不清楚就开始动手写了，写完后，上线的代码，不一定有把握，所以不敢重构，看来还是得多些代码才行。

6.程序块注释的组织

最好将相同模块的方法用：
---------比赛场-------------

---------金币场-------------

---------通用---------------
 

...这样区分开来，还是不错的