“设置”应该在哪个包中班级安排？
我正在构建一个应用程序，但发现自己太容易创建新包，而没有记住项目的结构。
现在，我尝试先在纸上重做整个项目结构。我正在使用具有公共属性的 Settings 类，可作为项目中其他几个类的设置进行访问。
现在，由于这个 Settings 类适用于整个项目，我不确定它是否应该打包，如果是，它应该存在于什么样的包中？或者它应该与主应用程序类一起位于根目录（默认包）中？
我一直在考虑将其放入我的 utils 包中，但我再次认为它并不是一个真正的实用程序。关于如何决定此类包结构（例如设置类）的任何策略？
I'm in the middle of building an application but found myself too easily creating new packages without keeping the project's structure in mind.
Now, I'm trying to redo the whole project structure on paper first. I am using a Settings class with public properties, accessed as settings for several other classes around the project.
Now, since this Settings class applies for the whole project, I am unsure if it should be packaged and if so, in what kind of package should it exist? Or should it be in the root (the default package) with the main application class?
I've been thinking about putting it in my utils package, then again I don't think it really is an utlity. Any strategies on how to decide on such package structure for example for a Settings class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论如何，不鼓励使用默认包（据我所知，在 java 中它实际上是作为警告强制执行的），即使对于包含 main 的类也是如此。
除此之外，我更喜欢有一个 config 包，即使它是其中唯一的类。我认为它不适合 utils 包。
Use of the default package is discouraged anyway (in java it is actually enforced as a warning as far as I know), even for the class containing the main.
Other than that, I prefer having a
configpackage, even if it's the only class in there. I don't think it would fit in theutilspackage.恕我直言，您应该将它放入一个单独的低级包中，因为许多其他类依赖于它，但它（大概）不依赖于任何东西。因此，它绝对不应该与主应用程序类放在一个包中。它可以位于
utils包中，也可以位于同一级别的单独包中（例如config）。我所说的“低级别”只是指“包依赖层次结构较低”，其中依赖于包 B 的包 A 高于 B。因此它与实际的包层次结构没有直接关系。重点是避免包之间的依赖循环，以便您可以在包之间进行这样的排序。
顺便说一句，您不应该在实际应用程序中使用根包。
IMHO you should put it into a separate, low level package, since many other classes depend on it, but it (presumably) doesn't depend on anything. So it should definitely not be put in one package with the main application class. It could be in the
utilspackage though, or in a separate package on the same level (e.g.config).By "low level" I simply mean "low on the package dependency hierarchy", where a package A which depends on package B is higher than B. So it does not directly relate to the actual package hierarchy. The point is to avoid dependency cycles between your packages, so that you can have such an ordering between your packages.
Btw you should not use the root package in a real application.