《设计模式与游戏完美开发》总结

1. 通过外部设置最大生命力这种写法
2. 方法的参数做成父类非常的好
3. 当流程相似的时候赶紧使用模板方法模式
4. 把别人类，做成自己的静态类成员即可解决顺序问题
5. 抽象方法本来就是模板，里面再做抽象方法的模板，真是绝了
6. 一个状态机两个不同人使用
7. 场景也能做成状态模式
8. 既是外观又是中介者
9. 多对多使用桥接模式
10. 考虑到if,switch都可以重构成策略
11. 状态模式某个函数用了很多的return,还有哪怕在update里面都没关系，因为进入另外一个状态就不执行update了
12. 角色属性单独抽离成类，是类的还有成就系统，行动力系统，事件系统，兵营，关卡，角色管理
13. 游戏循环模式顺序：输入，逻辑，画面
14. 使用虚方法重载更灵活一点
15. 抽象类中的this，是子类还是父类看传入的环境，状态模式new一个的状态的话，状态类是会丢失数据的
16. Update靠return做成分段代码还是很不错的
17. 代码风格：从上到下，public,protected,private,注释一律右侧打啊，const一律用readyOnly和枚举一样也都要用大写，函数名字长点无所谓表达清楚就行
18. 一些极限值的处理做成是否可以删除或者增加的这种形式
19. 工厂方法还要有接口
20. 当一个孙系统需要和多个子系统沟通时，就把它变成子系统
21. 参数类都做成了抽象类，其实也很有意义，因为可以避免修改
22. 属性工厂
23. 构建流程做成虚函数没有功能就不实现，工厂类生产，组装类组装角色，子弹特效也可用于建造者模式
24. 属性类也是抽象，武器类的儿子武器属性类，武器属性和角色属性分开
25. 亨元属性会变的和不会变的做个区分，这个模式自然要用到工厂类
    ，共享的放字典啊
26. Mathf.Min()规避极限值
27. 所有兵营做成对象，用字典来管理
28. 集中管理的好处是逻辑既不重复也不分散
29. 关卡内容也做成类，责任链模式对boss关卡和普通关卡的应用
30. 都是以一个逻辑块来做模块化
31. 事件系统字典存事件和事件的观察者
32. 备忘录模式保存一个存档也是有优势的，不公开数据就算是一个优势
33. 角色信息查询对应访问者模式，不用更改两个类，子类带不带数据跟数据唯一性有关，访问一次reset一次
34. 使用装饰者模式应用的前缀和后缀，可给属性和道具增加多样性，加成的属性做成一个类，交给属性工厂管理
35. 强化角色也可应用装饰者模式
36. 俘兵改造成友军用适配器模式但是推荐后期使用，而且前提敌我属性要有共同的父类
37. 代理模式开启是否优化，资源工厂存放已经加载过的，代理模式新功能是否要执行（加一个bool控制）。适配器是组合生命周期，代理是聚合生命周期
38. 参数类是非常好的一项设计
39. 中介类还能减少接口
40. 除了单例，还有静态类、方法来用
41. 单例模式少用
42. 返回接口就是了，没必要把策略的接口又写进去
43. 策略模式不一定只运用于算法上，还可以是初始化
44. 函数划分也很重要
45. 建造模式比模板模式更低耦合
46. 属性工厂的设置，而且是带ID
47. 是否懒加载，看资源大小
48. 设计模式的类有可能有多种职责
49. 既有角色管理又有兵营管理，访问者就到角色管理那里去，访问到信息又返回给UI
50. Update中的return, return, return
51. 命令模式不是越多越好啊
52. 成就系统和事件分清关系，单个观察者就是一个类，方便写，很强大，缺点也明显，事件多，类也多
53. 前后缀装饰着还带着buff呢，工厂管理持有装饰的属性
54. 适配器模式隔离第三方库
55. 代理模式对想要功能控制，用于测试等，还有加载更友好
56. 交战双方设置一个中介来管理
57. 属性工厂