>背景
我有以下几点：
类火延伸元件，
类木材延伸元件，
类 复合元素的磁贴。
Tile 类表示世界/屏幕/画布中的磁贴，并且具有一些图形和逻辑功能。 它合成了一个 Element 对象，因为"世界"中的每个图块都是由某种物质(=元素)组成的。
我想实现火蔓延的功能 - 当火元素"接触"木元素时，我希望木元素变成火。 从逻辑上讲，这应该在火元素中完成，但这样做，我无法更改给定的瓷砖元素(例如从木头到火)。
"世界"被初始化为由木元素组成的瓷砖网格，除了一个瓷砖具有应该扩散的火元素。
我尝试过什么
我尝试将元素链接在一起，这意味着每个元素都可以访问他的四个最近邻居。这样，火就可以进入附近的一块木头。 这并不能解决当火接触木材时更改瓷砖元素类型的问题。
我尝试将整个功能移动到 Tile 类。虽然它确实解决了问题，但我不喜欢它有两个原因：
-
从逻辑上讲，我希望火是自主行动的，这意味着火是蔓延的，而不是瓷砖。
-
因此，Tile 类有许多只与火相关的方法(例如 spread())，这需要我检查 - "这个图块是由火元素组成的吗？"，这是不好的做法。
代码示例
class Fire extends Element{
public void spread(){
// Move to all four neighbors and turn them into Fire elements
}
}
class Wood extends Element{
}
class Tile{
private Element _element;
}
深入
磁贴的"网格"由一个二维的图块数组(逻辑部分)和一个由所有图块组成的 JavaFx 窗格(可视部分)组成。
当火碰到相邻的瓷砖并将其从木头变成火时，它就会"蔓延"。当火消耗(=改为火)给定的木材阈值时，例如在消耗了 30 块木材之后，火停止蔓延。从某种意义上说，火可以跟踪它消耗的木材。
提前感谢！
我瞬间想到应该有一个类来管理火势蔓延。比方说，有一个World类，一个知道瓷砖网格及其性质的类。Fire对Wood一无所知，它的位置，它的邻居。Wood也是如此.它们是过着自己生活的独立对象。World决定他们居住的地方以及他们如何相互交流。
让我们想象一下Fire发布一个事件并告诉
我想传播。以下是我想占据的位置。我的身高/强度/频率/我的[火的任何其他特征]是......">
World接收消息，考虑火灾的特征，并相应地修改网格。
还行。有了火的这种强度/高度/[任何其他特征]，这个和这个
Wood元素将被燃烧。我将用新的Fire实例替换它们(或者我将复制现有的Fire对象，并将对它的引用放入预期的要刻录的单元格中)。
有一个Fire实例并跟踪它燃烧的所有元素会很有趣。我可以看到复制构造函数的修改版本。
Fire(Fire current, Elements... newlyTakenElements)
不过，您可以自由地找出自己的记录方式。
有了这个，您将能够在火灾结束时(全部或部分)恢复细胞。您还可以分析火势的发展情况。我不确定这是否会派上用场，但设计起来很吸引人。
我正在考虑替代方案...我仍然认为向Fire提供太多信息(整个图块地图)不是一种方法，Wood和Fire单元格之间的任何交互都应该通过管理器类。
看看另一个场景，它表明World提供了自身的部分视图，作为与火元素相邻的列表。
-我想传播。
-还行。以下是相邻可燃元素的列表。我不知道你的特点。由您决定要燃烧多少细胞(以及哪些细胞)。
-我把它们都烧了。给我更多！
世界给出了另一个清单，直到火被满足。