组件模式

组件模式

谈一谈继承与组合

当面向对象语言第一次接触这个场景时，继承是它箱子里最闪耀的工具。 它被认为是代码无限重用之锤，编程者常常挥舞着它。 然而我们痛苦地学到，事实上它是一把重锤。 继承有它的用处，但对简单的代码重用来说太过复杂。相反，在今日软件设计的趋势是尽可能使用组件代替继承。 不是让两个类继承同一类来分享代码，而是让它们拥有同一个类的实例。

使用场景

组件通常在定义游戏实体的核心部分中使用，但它们在其他地方也有用。 这个模式应用在在如下情况中：

• 有一个涉及了多个领域的类，而你想保持这些领域互相隔离。

• 一个类正在变大而且越来越难以使用。

• 想要能定义一系列分享不同能力的类，但是使用继承无法让你精确选取要重用的部分。

有得有失

• 优点：解耦与重用
• 挑战：

组件模式相较直接在类中编码的方式为类本身引入了更多的复杂性。每个概念上的“对象”成为一系列必须被同时实例化、初始化，并正确关联的对象的集群。不同组件之间的通信变得更具挑战，而且对它们所占用内存的管理将更复杂。

另一个影响是，往往需要通过一系列的间接引用来处理问题，即从容器对象获取到组件，再调用组件的方法。

组件之间传递信息

下面列举的方法不是互斥的：

1. 通过修改容器对象的状态
   • 优点：组件保持解耦。
   • 缺点：
     • 组件间需要共享的数据都由容器对象来保管。但是通常某些数据只被少部分组件所需要。所有数据都在容器类中，会让它混乱。更糟的是，如果我们为不同组件配置使用相同的容器类，最终会浪费内存存储不被任何对象组件需要的状态。
     • 这让组件的通信基于组件运行的顺序。
2. 通过它们之间相互引用
   • 优点：简单快捷。
   • 缺点：两个组件紧绑在一起。
3. 通过发送消息
   • 优点：
     • 同级组件解耦。
     • 容器类很简单。
   • 缺点：
     • 逻辑复杂。
     • 增加了开销。

原作者按：

不出意料的，这里没有最好的答案。这些方法你最终可能都会使用一些。 共享状态对于每个对象都有的数据是很好用的——比如位置和大小。

有些不同领域仍然紧密相关。想想动画和渲染，输入和AI，或物理和粒子。 如果你有这样一对分离的组件，你会发现直接相互引用也许更加容易。

消息对于“不那么重要”的通信很有用。对物理组件发现事物碰撞后发送消息让音乐组件播放声音这种事情来说，发送后不管的特性是很有效的。

就像以前一样，我建议你从简单的开始，然后如果需要的话，加入其他的通信路径。