自定义 Java 实用程序包
我当前项目中的一个常见操作是将 IP 地址的字符串版本转换为整数表示形式，并且可以通过单个静态方法轻松处理。我通常会尝试使其尽可能接近使用它的代码，但应用程序的完全不同部分也需要它。
由于在非常不同的包中让类相互引用这一实用函数似乎是有害的，因此我创建了一个 util 包并移动了静态方法（一个用于 int 到 String，一个用于 String 到 int） ) 到该包中的 Ip 类中。
我认识到这可能是一个迹象，表明我应该重新考虑项目的组织，但是添加一个包来保存项目范围的实用功能有什么害处吗？ Java 中有处理这种情况的标准方法吗？
A common operation in my current project is converting a string version of an IP address into an integer representation, and it's easily handled by a single static method. I would normally try to keep this as close to the code that uses it as possible, but it's also needed in completely different parts of the application.
Since it seemed harmful to have classes in very different packages referring to each other for this one utility function, I created a util package and moved the static methods (one for int to String, one for String to int) into an Ip class in that package.
I recognize that this is probably a sign that I should rethink the project's organization, but is there anything harmful about adding a package to hold project-wide utility functions? Is there a standard way to handle this situation in Java?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这是一个普遍的问题，不仅仅是 Java 的问题。
“因为它看起来有害”——有什么危害？耦合？单点故障？
您可以通过一个示例准确地说明您在 JDK 本身中所做的事情：
java.util有许多到处都在使用的类。我认为你的设计是站得住脚的。保持这种状态，直到经验告诉你一个更好的地方来放置该类。
您应该警惕的一件事是循环依赖。您的 util 包中没有任何内容依赖于其任何依赖项。如果必要的话，用接口打破循环。
It's a generic problem, not just Java.
"Since it seemed harmful" - what's the harm? Coupling? Single point of failure?
You have an example of exactly what you did in the JDK itself:
java.utilhas lots of classes that are used all over the place.I think your design is defensible. Keep it that way until experience tells you a better place to put that class.
The one thing you should guard against is cyclic dependencies. Don't have anything in your util package depend on any of its dependencies. Break cycles with interfaces if you must.
我不认为这有什么问题。事实上，如果您发现有多个属于同一问题域的此类特定操作，并且并非都可以在第三方库中方便地使用，或者您希望避免添加对外部代码的额外依赖项，那么您可能会非常担心。我们会把它变成一个单独的项目。拥有一个自己的 utils jar 以便在整个应用程序中重复使用可能会很好。
据我所知，通过识别一段将被重用的代码并将其单独放置在某个地方，您做了完全正确的事情。
I don't see anything wrong with that. As a matter of fact, if you find you have multiple such specific operations that belong in the same problem domain and aren't all conveniently available in third-party libraries, or you wish to avoid adding additional dependencies on external code, you may very well turn this into a separate project. A utils jar of your own for reuse throughout your apps could be good to have around.
As far as I can tell, you did the exact right thing by identifying a piece of code that will be reused and placing it somewhere separately for that purpose.
就我个人而言，我会做类似于你所做的事情。我通常在基础包中为项目范围的实用程序函数创建一个
util包，我知道这些函数将在我的整个项目中使用。如果我需要一个仅由特定类使用的实用函数，则该类本身可以处理它。如果我需要一个由特定包中的类使用的实用程序，请在该包中创建一个
util包。只是我的两分钱。
Personally I would have done something similar to what you have done. I usually create a
utilpackage in the base package for project wide utility functions that I know are going to be used throughout my project.If I need a utility function that is only used by a specific class, the class itself can handle it. If I need a utility that will be used by classes in a specific package, create a
utilpackage in that one.Just my two cents.
并不真地。 util 包的存在是有原因的，即保存 util 类。
特别是当它在其他包中有用时。所以它可以是您分类的逻辑顺序
Not really. util packages exist for a reason, to hold util classes.
Especially when it is useful across other packages. So it can be a logical sequence for your classification
我不知道它是否“正确”，但我想我可能在我从事过的每个项目中都有某种类型的实用程序包。
I don't know if it's "correct" but I think I've probably had some type of utility package in every project I've ever worked on.
我只想添加“高扇入”作为此类实用程序类的术语。来自Code Complete（第二版），将其称为“设计的理想特征”之一”：
I'd just like to add "high fan-in" as a term for such utility classes. From Code Complete (2nd Ed.) referring to it as one of several "desirable characteristics of a design":
实用程序类是定义一组执行常见且经常重复使用的功能的方法的类。大多数实用程序类在静态范围内定义这些通用方法。实用程序类的示例包括 java.util.Collections，它为实现 Collection 的对象提供多种实用程序方法（例如排序）。
实用程序类应该始终是最终的并且具有私有构造函数。
a utility class is a class that defines a set of methods that perform common, often re-used functions. Most utility classes define these common methods under static scope. Examples of utility classes include java.util.Collections which provides several utility methods (such as sorting) on objects that implement a Collection.
Utility classes should always be final and have a private constructor.