为什么在跨团队创建依赖性时使用枚举？
Why use enums when it creates dependency across teams?
我知道当我们只希望传递一组值时会使用枚举。我们不希望调用者传递定义明确的集合以外的任何内容。
这在项目中非常有效。因为你知道你要传递什么。
但是考虑2个项目，我在第2个项目中使用第一个项目的模型。
第二个项目有这样的方法
public void updateRefundMode(RefundMode refundMode)
enum RefundMode("CASH","CARD","GIFT_VOUCHER")
现在，我意识到 RefundMode 也可以是 PHONEPE，所以如果我开始将它传递给第一个项目，它最终会失败（无法反序列化枚举 PHONEPE）。虽然我在最后添加了这个枚举。
这很好，因为如果我的第一个项目不知道“PHONEPE”，那么它就不知道如何处理它，所以他也必须更新模型。
但我的问题是，让我们想象一个复杂的对象正在尝试传递，它也采用此 RefundMode，当我传递一个新的 RefundMode 时，这个字段应该在它们的末尾变为 null 或被忽略，对吗？而不是不接受整个对象，并打破整个flow/request.
有没有一种方法可以指定 jackson (jsonproperties) 在传递未知值时忽略该字段。很想知道..（虽然在那种情况下，我打破了 ENUM 的规则）那么，为什么不保留一个解决所有问题的字符串？
一切都与合同有关。
当你处于 client/server 的情况下，作为一个移动应用程序和一个网络服务器，或者一个 Java 库（jar）和另一个 Java 项目，你必须保持心中的合同。
如您所见，合同的变更需要传播到双方：客户端和服务器（供应商）。
处理此问题的一种方法是使用版本控制。你可能会说：“版本 1：这些是退款模式。”。然后移动应用程序可以通过在URL中指定合约版本来调用网络服务器：/api/v1/refund?mode=CASH
当合同需要更改时，您需要考虑如何处理客户。对于移动应用程序，用户可能没有将他们的应用程序更新到最新版本，因此他们的应用程序可能仍在调用 /api/v1（并且不支持新的退款模式）。在这种情况下，您可能希望在您的网络服务器中同时支持 /api/v1 和 /api/v2（使用新的退款模式）。
如您的示例所示，并非总是可以透明地将一个合同版本改编为另一个合同版本（在您的示例中，原始枚举中没有 PHONEPE 的等价物）。如果你必须处理合约更新，我建议明确地为它们编写代码（你可以使用专用的 JSON 模式、类 和服务）而不是试图弥合差距。想想第三个、第四个版本会发生什么。
编辑：要回答您的最后一个问题，您可以按照以下答案忽略 JSON 中的未知字段（带有上述说明的注意事项）：
编辑2：一般来说，使用枚举是strong typing的一种形式。当然，您可以使用字符串，甚至位，但这样会更容易出错，例如使用 GiftVoucher 而不是 GIFT_VOUCHER.
我知道当我们只希望传递一组值时会使用枚举。我们不希望调用者传递定义明确的集合以外的任何内容。 这在项目中非常有效。因为你知道你要传递什么。
但是考虑2个项目，我在第2个项目中使用第一个项目的模型。
第二个项目有这样的方法
public void updateRefundMode(RefundMode refundMode)
enum RefundMode("CASH","CARD","GIFT_VOUCHER")
现在，我意识到 RefundMode 也可以是 PHONEPE，所以如果我开始将它传递给第一个项目，它最终会失败（无法反序列化枚举 PHONEPE）。虽然我在最后添加了这个枚举。
这很好，因为如果我的第一个项目不知道“PHONEPE”，那么它就不知道如何处理它，所以他也必须更新模型。
但我的问题是，让我们想象一个复杂的对象正在尝试传递，它也采用此 RefundMode，当我传递一个新的 RefundMode 时，这个字段应该在它们的末尾变为 null 或被忽略，对吗？而不是不接受整个对象，并打破整个flow/request.
有没有一种方法可以指定 jackson (jsonproperties) 在传递未知值时忽略该字段。很想知道..（虽然在那种情况下，我打破了 ENUM 的规则）那么，为什么不保留一个解决所有问题的字符串？
一切都与合同有关。
当你处于 client/server 的情况下，作为一个移动应用程序和一个网络服务器，或者一个 Java 库（jar）和另一个 Java 项目，你必须保持心中的合同。
如您所见，合同的变更需要传播到双方：客户端和服务器（供应商）。
处理此问题的一种方法是使用版本控制。你可能会说：“版本 1：这些是退款模式。”。然后移动应用程序可以通过在URL中指定合约版本来调用网络服务器：/api/v1/refund?mode=CASH
当合同需要更改时，您需要考虑如何处理客户。对于移动应用程序，用户可能没有将他们的应用程序更新到最新版本，因此他们的应用程序可能仍在调用 /api/v1（并且不支持新的退款模式）。在这种情况下，您可能希望在您的网络服务器中同时支持 /api/v1 和 /api/v2（使用新的退款模式）。
如您的示例所示，并非总是可以透明地将一个合同版本改编为另一个合同版本（在您的示例中，原始枚举中没有 PHONEPE 的等价物）。如果你必须处理合约更新，我建议明确地为它们编写代码（你可以使用专用的 JSON 模式、类 和服务）而不是试图弥合差距。想想第三个、第四个版本会发生什么。
编辑：要回答您的最后一个问题，您可以按照以下答案忽略 JSON 中的未知字段（带有上述说明的注意事项）：
编辑2：一般来说，使用枚举是strong typing的一种形式。当然，您可以使用字符串，甚至位，但这样会更容易出错，例如使用 GiftVoucher 而不是 GIFT_VOUCHER.