我对设计的意见感兴趣。
至少有两种方法可以找到常用数据的集合。在main方法之外，所有方法都可以访问相同的Collection并更改它的数据。或者2，在main中我可以根据需要制作尽可能多的集合，并将它们作为arg传递给函数，对象或方法。
哪个更好？我的想法告诉我，2导致代码更容易重用并具有更好的数据封装。但是，我看到很多例子中的1个告诉我1可能会更好。但是，为什么？
答案 0 :(得分：2)
完全取决于使用情况。封装类可能具有列表作为实例状态。有时它完全不合适，传递/返回状态更有意义。
没有“更好”，只有“适当”。
从评论回复中移出
有意义的是依赖于上下文。类具有属性 - 列表是完全有效的属性。毕竟，如果你有一个“人”类，你就不会传递“名字”属性;这是一个属性。
如果你发现某些东西在内部传递了一个“很多”，也许它是一个属性而不是另一个类，或者......相反，如果它只是松散地与类相关联而不是它的内部表示的一部分，它将列表作为本地和/或参数可能更有意义。
有时它只是美学或便利的问题。
答案 1 :(得分：1)
通常，字段不应在声明它们的类之外访问。如果您将集合的示例看作Main类中的字段，这些字段可能被其他类访问，这可能不是很好的设计。如果只使用类中的方法访问集合，那很好。如果其他类需要访问集合，则应该通过一些机制来获取集合（传递集合，或传递具有getter的对象）。
答案 2 :(得分：1)
大多数开发人员正在开发一个级别 - 专注于类之间的交互，而不是一个。从理论上讲，你是对的，但在实践中，它通常不是很重要 - 理解类私有集合的使用通常很容易 - 如果你只是选择任何出现的名称，大多数IDE甚至会突出显示所有用法。由于IDE的帮助，最终在您的样式中编写的代码中更难跟踪数据流。但是，在考虑类间用法时，你的直觉是正确的。
需要模型的情况是类需要无状态时 - 特别是在多个线程同时调用它的实例的情况下。在这种情况下，任何每线程数据通常都不能存储在类级别，并且必须在函数之间传递。
答案 3 :(得分：1)
您希望自己处于一个可以重新访问代码的位置，并确切知道每个部分应该做什么，以及 正在做什么。
为此，显而易见的（在适当的软件工程中最常用）更像是第二个。
尝试并创建清晰的分离。问自己一些问题，例如：