Java 当有许多子类时，代码是否优雅？

我有一个有趣的编程问题，已经困扰了我好几天了。以下是一些有助于我提出问题的背景：

目前我正在编写一个游戏，使用材质Emum来保存游戏中所需的所有材质，即Material.dirty、Material.WATER、Material.CLOTH

然而，我希望使代码尽可能的可修改，并有能力，如果有人想扩展游戏添加新的材料，他们可以这样做。因此，我当前的枚举系统出现故障，因此我尝试切换到类/子类系统。我找到了两种方法来实现这一点，下面将解释它们的优缺点

案例1-具有抽象材料类和子类。 因此，每种材料都会延伸到材料。这是有利的，因为我们现在可以将类似材料“分组”，即织物可以扩展材料，然后羊毛和棉花等可以扩展材料。这样做的问题是，对于每种材质，都必须存在一个类，并且每种材质的参数都非常少，感觉像是浪费。如果有1000种材料，那么就有1000种类别，而实际上它们都没有任何内容。我可以通过使用匿名类来减少这种情况，但现在代码无法区分不同的材料。我可以使用身份证系统，这是案例2的主要问题

案例1的问题是： 有没有更优雅的方法

案例2-具有单个材质类，并将每个新材质实例化为该类的实例，用不同的id/名称定义每个材质。这节省了大量的文字，也使我们能够区分不同的材料。问题是，现在我们有了一个id系统，这个系统的基础是什么？字符串，整数？我这样问是因为我一直渴望拥有一个复杂的自由系统，避免在代码中使用硬编码字符串和int。这就是为什么我喜欢Enum，因为不必担心排版问题。另一个问题是，想要添加新材质的用户可能与其他用户的ID冲突

关于案例2，我的问题是： 是否有一种完全证明方法能够唯一且一致地区分实例（每个运行时都是相同的）

谢谢你的阅读。任何关于如何最好地做到这一点的帮助或方法都将不胜感激

---

编辑：我应该注意一些材料可能有与之相关的方法和行为。某些行为可能是某些材质独有的，而某些行为与“组”相似。

使用配置文件，其中包含所有材质，并以某些DSL（基本上是简单的表格）编写。

有一个

界面，材质要求您返回，例如
字符串materialName（）
。
界面
还可能要求返回
材质
-
getStrength（）
等的各种行为。然后让您的
枚举
为您的内部材质实现该
界面
。如果需要，其他人可以提供他们自己的实现。我尝试了枚举和其他各种方法（接口等），但没有一种效果很好。另一种方法是下面Elazar所说的。在编辑之后，我建议使用访问者模式来访问材料的属性——这样你就不必直接暴露行为，你可以利用多态性来切换行为。这将要求您使用
案例1
，并将所有内容隐藏在
界面后面。使用访问者模式，您不必区分材料，因此不需要ID，您可以使用匿名类，只要它们覆盖相关的
accept
方法来更改其行为。感谢您的输入。我觉得这种结合使用访问者模式的界面方法是最好的方法，并且对这个项目非常有效。我想这是我更愿意接受的答案。我认为不同的材料可能有不同的行为，这就是多态性的原因。如果是这样的话，那么这个解决方案将很难实现（Drules？）。这取决于实现，但我相信简单事物的行为，例如游戏中的材料，可以很容易地编码到表中。同意，您得到我的+1。但是如果OP想要某种访客图案（这是有意义的——比如说一件衣服是用几种材料做成的，并且被裁剪了或是其他类似的），那么这就很麻烦了。你说得对。我想我的回答更像是第三个案例来考虑。