关于unity组件化开发的一点想法

最近在学习unity，顺便开发一点小游戏练练手，发现不同的游戏开发总有不同的方式，相同的功能总有不同的实现方法，于是想着哪个是最优，如何设计游戏架构最好，至少要有一个统一的原则，也就不用每次都冥思苦想一番，能有一个大致的框架和底线。

后来上网查了一下资料，发现其实最好最普遍的方法其实还是在unity自身上，“组件化”，的开发方式。

所谓组件化，就是写脚本不要当作写对象一样，不要去定义“这是个什么”，而是去写“这个东西能做什么”，前者更关注存在，而后者更偏向过程，是一种功能。而且，“这个东西能做什么”往往还能够复用，比如给不同的对象加上相同的功能。

此时，还可以通过开关不同的组件实现不同的组合，达到不同的效果，使用组件化而不是对象化更多的参考了“组合优于继承”的思想。

然而这样却也并非万能灵药，虽然组件化看上去很好，但其实很多地方仍然需要一些对象，比如一个功能，一种能力，有时候可能需要和外部数据交互，比如根据某个全局数据的值来进行判断，这时候可能还需要写一个对象挂一个脚本用来存储全局数据，再比如，一个对象有很复杂的组件逻辑，需要实现不同组件的组合，那么还可能需要写一个控制器挂在上面，这个控制脚本的专用性很强，几乎可以看作为那个特定的对象专门开发的内容，这样也失去了组件的泛用性。

但已经很好了，写一个player的移动逻辑，未必要写一个player的脚本挂在上面然后在update里面反复判断按键，而是写一个move脚本，其中写移动的逻辑，这样的整体设计能够更好的复用代码功能，而且将复杂的功能拆解成简单的脚本也有利于减少心智负担和后期的维护成本，增强灵活性。

怎么说呢，软件开发没有银弹吧。