我想知道什么时候使用静态方法?假设我有一个类,有几个getter和setter,一个或两个方法,我希望这些方法只能在类的实例对象上调用。这是否意味着我应该使用静态方法?
例子:
Obj x = new Obj();
x.someMethod();
或:
Obj.someMethod(); // Is this the static way?
我很困惑!
我想知道什么时候使用静态方法?假设我有一个类,有几个getter和setter,一个或两个方法,我希望这些方法只能在类的实例对象上调用。这是否意味着我应该使用静态方法?
例子:
Obj x = new Obj();
x.someMethod();
或:
Obj.someMethod(); // Is this the static way?
我很困惑!
当前回答
静态方法不需要在对象上调用,这就是你使用它的时候。例如:你的Main()是一个静态的,你没有创建一个对象来调用它。
其他回答
静态方法是一种不需要初始化任何对象就可以调用的方法。你注意到静态是用在Java的main函数中吗?程序从那里开始执行,不需要创建对象。
考虑下面的例子:
class Languages
{
public static void main(String[] args)
{
display();
}
static void display()
{
System.out.println("Java is my favorite programming language.");
}
}
在阅读了Misko的文章之后,我相信静态方法从测试的角度来看是不好的。相反,您应该使用工厂(可能使用像Guice这样的依赖注入工具)。
我如何确保我只有一个东西
只吃一种 问题是"我如何确保我 只吃一种东西”是很好的 回避了。实例化一个 单个ApplicationFactory在你的 主要的,结果,只有你 实例化所有的单个实例 你的独生子女。
静态方法的基本问题是它们是过程代码
静态方法的基本问题是 它们是过程代码。我没有 知道如何对过程代码进行单元测试。 单元测试假设我可以 实例化我的应用程序的一部分 在隔离。在实例化过程中 我将依赖项与 mock /友军替换 真正的依赖关系。与程序 编程没有什么可以“连接”的 由于没有对象,代码 数据是分开的。
一个经验法则:问问自己“即使还没有构造对象,调用这个方法有意义吗?”如果是这样,它肯定是静态的。
在Car类中,你可能有一个方法:
double convertMpgToKpl(double mpg)
...这将是静态的,因为有人可能想知道35英里/加仑转换成什么,即使没有人制造过汽车。但是这个方法(设置一个特定Car的效率):
void setMileage(double mpg)
...不能是静态的,因为在构造任何Car之前调用该方法是不可想象的。
(顺便说一下,相反的情况并不总是正确的:你可能有时有一个方法涉及两个Car对象,但仍然希望它是静态的。例如:
Car theMoreEfficientOf(Car c1, Car c2)
虽然这可以转换为非静态版本,但有些人会认为,由于没有“特权”选择哪个Car更重要,所以不应该强迫调用者选择一个Car作为调用方法的对象。不过,这种情况在所有静态方法中只占相当小的一部分。
静态方法有两个主要目的:
用于不需要任何对象状态的实用程序或辅助方法。 由于不需要访问实例变量,具有静态 方法消除了调用方实例化对象的需要 只需要调用这个方法。 为了所有人共享的状态 类的实例,比如计数器。所有实例必须共享 相同的状态。仅仅使用该状态的方法应该是静态的 好。
使用静态方法有一些合理的理由:
Performance: if you want some code to be run, and don't want to instantiate an extra object to do so, shove it into a static method. The JVM also can optimize static methods a lot (I think I've once read James Gosling declaring that you don't need custom instructions in the JVM, since static methods will be just as fast, but couldn't find the source - thus it could be completely false). Yes, it is micro-optimization, and probably unneeded. And we programmers never do unneeded things just because they are cool, right? Practicality: instead of calling new Util().method(arg), call Util.method(arg), or method(arg) with static imports. Easier, shorter. Adding methods: you really wanted the class String to have a removeSpecialChars() instance method, but it's not there (and it shouldn't, since your project's special characters may be different from the other project's), and you can't add it (since Java is somewhat sane), so you create an utility class, and call removeSpecialChars(s) instead of s.removeSpecialChars(). Sweet. Purity: taking some precautions, your static method will be a pure function, that is, the only thing it depends on is its parameters. Data in, data out. This is easier to read and debug, since you don't have inheritance quirks to worry about. You can do it with instance methods too, but the compiler will help you a little more with static methods (by not allowing references to instance attributes, overriding methods, etc.).
如果你想创建一个单例,你还必须创建一个静态方法,但是…不喜欢。我的意思是,三思而后行。
更重要的是,为什么不想创建静态方法?基本上,多态被抛在了脑后。你不能重写这个方法,也不能在接口中声明它(在java 8之前)。这给你的设计带来了很大的灵活性。此外,如果您需要状态,如果您不小心,您将以大量并发错误和/或瓶颈告终。