有必要遵循防御性编程实践以获取永远不会公开获得的代码？

我正在编写纸牌游戏的Java实现，因此我创建了一种特殊的Collection类型，称为“区域”。不支持Java的Collection的所有修改方法，但是Zone API中有一种方法，该方法move(Zone, Card)可将Card从给定的Zone移到其自身（由package-private技术实现）。这样，我可以确保没有任何卡被带出区域并消失。它们只能移到另一个区域。

我的问题是，这种防御性编码有必要吗？这是“正确的”，并且感觉像是正确的做法，但这并不意味着Zone API永远不会成为某些公共库的一部分。这只是给我的，所以这有点像是在保护我自己的代码，以免仅使用标准Collections可能会提高效率。

我应该把这个区域创意带到多远？谁能给我一些建议，让我考虑在我编写的类中保存合同，特别是对于那些不会真正公开可用的类，应该考虑些什么？

我不会解决设计问题-只是在非公开API中是否“正确”执行操作的问题。

这只是给我的，所以有点像我在保护自己的代码

这就是重点。也许那里的编码人员会记住他们曾经编写的每个类和方法的细微差别，并且永远不会以错误的合同错误地调用它们。我不是其中之一。我经常忘记编写的代码应该在编写后的几个小时内起作用。如果您认为问题已经得到了它的权利一次，你的头脑会倾向于齿轮切换到你的工作问题现在。

您有打击该问题的工具。这些工具包括（无特定顺序）约定，单元测试和其他自动化测试，前提条件检查和文档。我本人已发现单元测试非常宝贵，因为它们既迫使您考虑如何使用合同，又在以后提供有关接口设计方式的文档。

我通常遵循一些简单的规则：

• 尝试始终按合同进行编程。
• 如果一种方法是公开可用的或从外界获得输入，请采取一些防御措施（例如IllegalArgumentException）。
• 对于只能在内部访问的所有其他内容，请使用断言（例如assert input != null）。

如果一个客户真的很喜欢它，他们总是会找到一种使您的代码行为异常的方法。他们至少可以总是通过反思来做到这一点。但这就是合同设计的美。您不赞成这种使用代码的方式，因此不能保证它会在这种情况下运行。

对于您的特定情况，如果Zone不应由外部人使用和/或访问，则可以将类设为package-private（可能是final），或者最好使用Java已经提供给您的集合。它们已经过测试，您不必重新发明轮子。请注意，这不会阻止您在整个代码中使用断言来确保一切正常。

防御性编程是一件非常好的事情。
直到它开始妨碍编写代码。那就不是一件好事了。

讲得更务实一点...

听起来您就将事情推到了极限。挑战（以及对问题的答案）在于理解什么是业务规则或程序要求。

以您的纸牌游戏API为例，在某些环境下，防止欺诈的所有措施都很关键。可能涉及大量的真实货币，因此有意义的是进行大量检查以确保不会发生作弊行为。

另一方面，您需要牢记SOLID原则，尤其是单一责任。要求容器类有效地审核卡片的去向可能会有些麻烦。在卡容器和接收移动请求的功能之间最好有一个审计/控制器层。

与这些问题相关，您需要了解API的哪些组件公开（因此容易受到攻击）与私有的组件和较少公开的组件。我并非完全主张“内部具有柔软内部的硬质涂层”，但最好的回报是使API的外部变硬。

我认为，库的最终用户并不会对确定要部署多少防御性程序的批评那么严格。即使使用我自己编写的模块，我仍然采取适当的检查措施，以确保将来我在调用该库时不会犯一些无意的错误。

防御性编码不仅仅是公共代码的好主意。对于不立即丢弃的任何代码来说，这都是一个好主意。当然，您知道现在应该如何调用它，但是您不知道从现在起六个月后回到项目时会如何记得。

与较低级的或解释性的语言（例如C或Javascript）相比，Java的基本语法为您提供了很多可靠的防御。假设您清楚地命名方法并且没有外部“方法排序”，则可以通过简单地将参数指定为正确的数据类型并在合理类型的数据仍然无效的情况下包含明智的行为来摆脱困境。

（顺便说一句，如果纸牌总是必须位于区域中，我认为通过将所有正在使用的纸牌都引用到游戏对象的全局集合中，您会获得更好的性价比，并且将Zone设为的属性每张卡。但是由于除了持卡外，我不知道您的区域有什么用途，因此很难知道这是否合适。）

首先创建一个保留区域列表的类，这样您就不会丢失区域或其中的卡片。然后，您可以检查传输是否在ZoneList中。此类可能是一种单例，因为您只需要一个实例，但是以后可能需要一组Zones，因此请保持打开状态。

其次，除非您期望使用Zone或ZoneList实现Collection或其他任何东西，否则不要使用它。也就是说，如果将Zone或ZoneList传递给期望Collection的对象，则实现它。您可以通过让它们抛出异常（UnimplementedException或类似的东西）或让它们简单地不执行任何操作来禁用一堆方法。（在使用第二个选项之前，请三思而后行。如果这样做，因为它很容易，您会发现自己丢失了可能早早发现的错误。）

关于什么是“正确的”，确实存在疑问。但是，一旦弄清楚了它是什么，您就会想用这种方式做事。两年之内，您会忘记所有这些，如果您尝试使用该代码，则会对以这种违反直觉的方式编写该代码并且什么都没解释的家伙感到非常恼火。

API设计中的防御性编码通常是关于验证输入并仔细选择适当的错误处理机制。其他答案提到的事情也值得注意。

这实际上与您的示例无关。出于非常特定的原因，您在那里限制了API的面。正如GlenH7所提到的，当要在实际游戏中使用一组纸牌时，例如具有（“二手”和“未二手”）卡组，一张桌子和一只手，您肯定要检查一下以确保每张纸牌都到位。集合中的卡片仅出现一次。

您使用“区域”设计此对象是一个任意选择。根据实现方式（在上面的示例中，区域只能是手，甲板或桌子），它可能是一个全面的设计。

但是，该实现听起来像是一组具有更多相似性的Collection<Card>卡，并且具有较少的API限制。例如，当您要构建一手价值计算器或一台AI时，您肯定希望自由选择要迭代的每张卡的数量和数量。

因此，如果该API的唯一目标是确保每张卡始终位于区域中，则最好公开这种限制性API。