Different behaviors can be obtained by using different service objects. Static methods in a utility class can't be swapped out. This is extremely useful for testing, changing implementations, and other purposes.
For example, you mention a CryptoUtil with an encrypt method. It would extremely useful to have different objects that could support different encryption strategies, different message recipients, etc.
Such a thing could be done with stateful session beans (as one example), although in that case authentication would probably be covered more traditional EJB mechanisms.
The point here is that there is conversational state in that the results of one call affects subsequent calls. You could view static methods as a bunch of simple stateless services that execute locally.
A service has a much broader meaning that includes, but is not limited to, being:
stateful;
remote; and
implementation dependent (ie through an interface).
Best practice I think is to simply use static methods as convenience methods (especially given Java's lack of extension methods). Services are much richer than that.
You cannot override static method, which can be a huge problem in case you'd like to implement your service in two different ways and switch between them. For this reason, I would limit the use of static utility classes to simple things which will "never" (for sufficiently long value of "never" :)) need to be done in more than one way.
I typically use static methods for functionality that requires few parameters, and can be accomplished in a single method call. Example:
calculate a hash value for a string
convert a date to standard representation
If a functionality requires many parameters, and if there are several related results being created, then it's more practical to have a classe that can accept the shared parameters in its constructor, with several methods that perform the actual action.
Typical example: A database connection, which you first connect, then use to do a query, then use to get the result...
I answered this question here somewhere before, but what I found was that it was very easy to change the behavior of a Service--to refactor it into multiple services--where it takes a pretty significant refactor if you use a static class.
If that is the only difference (and I believe it is), then it never makes any sense to use static classes.
Any time someone says "There will never ever ever be more than 1 of these", code for n of them.
发布评论
评论（5）
通过使用不同的服务对象可以获得不同的行为。 实用程序类中的静态方法无法交换。 这对于测试、更改实现和其他目的非常有用。
例如，您提到了带有
crypt方法的CryptoUtil。 拥有可以支持不同加密策略、不同消息接收者等的不同对象将非常有用。Different behaviors can be obtained by using different service objects. Static methods in a utility class can't be swapped out. This is extremely useful for testing, changing implementations, and other purposes.
For example, you mention a
CryptoUtilwith anencryptmethod. It would extremely useful to have different objects that could support different encryption strategies, different message recipients, etc.不同之处在于服务类可能有状态。 我所说的状态是指会话状态。 考虑一个名义上的订购系统。
这样的事情可以通过有状态会话 bean 来完成（作为一个示例），尽管在这种情况下，身份验证可能会涵盖更传统的 EJB 机制。
这里的要点是，存在一种会话状态，即一次调用的结果会影响后续调用。 您可以将静态方法视为一堆在本地执行的简单无状态服务。
服务具有更广泛的含义，包括但不限于： 有
我认为最佳实践是简单地使用静态方法作为便捷方法（特别是考虑到 Java 缺乏扩展方法）。 服务比这丰富得多。
The difference is that service classes might have state. And by state I mean conversational state. Consider a notional ordering system.
Such a thing could be done with stateful session beans (as one example), although in that case authentication would probably be covered more traditional EJB mechanisms.
The point here is that there is conversational state in that the results of one call affects subsequent calls. You could view static methods as a bunch of simple stateless services that execute locally.
A service has a much broader meaning that includes, but is not limited to, being:
Best practice I think is to simply use static methods as convenience methods (especially given Java's lack of extension methods). Services are much richer than that.
您无法覆盖静态方法，如果您想以两种不同的方式实现服务并在它们之间切换，这可能是一个大问题。 出于这个原因，我将静态实用程序类的使用限制为简单的事情，这些事情“从不”（对于足够长的“从不”值:)）需要以多种方式完成。
You cannot override static method, which can be a huge problem in case you'd like to implement your service in two different ways and switch between them. For this reason, I would limit the use of static utility classes to simple things which will "never" (for sufficiently long value of "never" :)) need to be done in more than one way.
我认为没有硬性规定。
我通常使用静态方法来实现需要很少参数的功能，并且可以在单个方法调用中完成。 示例：
如果某个功能需要许多参数，并且创建了多个相关结果，那么更实际的做法是拥有一个可以在其构造函数中接受共享参数的类，有几种执行实际操作的方法。
典型示例：数据库连接，您首先连接，然后用它来执行查询，然后用它来获取结果......
I think there are no hard and fast rules.
I typically use static methods for functionality that requires few parameters, and can be accomplished in a single method call. Example:
If a functionality requires many parameters, and if there are several related results being created, then it's more practical to have a classe that can accept the shared parameters in its constructor, with several methods that perform the actual action.
Typical example: A database connection, which you first connect, then use to do a query, then use to get the result...
我之前在这里回答过这个问题，但我发现改变服务的行为非常容易——将其重构为多个服务——如果使用静态类，则需要进行相当重要的重构。
如果这是唯一的区别（我相信是这样），那么使用静态类就没有任何意义。
每当有人说“永远不会有超过 1 个”时，就为其中 n 个进行编码。
I answered this question here somewhere before, but what I found was that it was very easy to change the behavior of a Service--to refactor it into multiple services--where it takes a pretty significant refactor if you use a static class.
If that is the only difference (and I believe it is), then it never makes any sense to use static classes.
Any time someone says "There will never ever ever be more than 1 of these", code for n of them.