Something came to my mind today. I have been doing a lot of the following
new Object().doSomething();
I create an object and call on of its functions, then forget about the object. I don't need it past this one instance. Does this signal a bad coding style. Is it best to convert these methods to a static function so a new object does not need to be created every time?
Creating an object only to call some method on it and then discard after the call is generally a bad idea. So, one possible solution is to convert that instance method to a static method. You can also leave it as an instance method but use only one instance of that class throughout the code. The latter can be enforced using the Singleton Pattern, as @AJC suggests.
But your question hides a deeper problem. Suppose that method doSomething() is being used in the context of business logic. In that case, whether you create the object in that context, or call a static method, or get a reference to the object via a Singleton, you are making your code very hard to test. In those three scenarios, the method call can't be mocked out from a unit test because the test cannot control how the object is instantiated. So, you are stuck with that "version" of the method, which, in turn, may call other static methods or Singletons, which may instantiate their own dependencies and so on and so forth. Therefore, even if you try to write a unit test for that method, you will end up testing a whole bunch of classes of your application at once. Besides, you are mixing business logic with object creation, violating the Single Responsibility Principle and making your code harder to maintain.
Your code should very rarely "go get" the dependencies it needs. Instead, it should only declare what it needs and let the responsibility of creating those dependencies to another class (typically called factories). This design technique is often referred to as dependency injection.
This depends offcourse in what exactly you are doing in that function and If you can call it as static or not. (static variables inside, etc...)
But from the way you seem to use it, the answer is yes. Either declare a static class or use the Singleton Pattern. But don't keep doing what you are doing. You are just having the overhead off instantiating a new object every time.
If for whatever reason you must use a new instance of an object, make sure you dispose of it when you are done.
Conceptually, you're already calling a static function, so the easy answer is to just go ahead and code them that way. A harder answer is that you probably have an underlying design flaw, such that this object is either a "misc" that you just threw a bunch of left over code into, or you are passing it a lot of state on each of those calls.
While they are all in that object, they're coupled, and you have less flexibility in refactoring the design. If you break it apart into just functions, then look at which go together, what state they are using, etc., you can move that functionality to where it belongs, either in one or more objects with discrete state, in the objects that are calling them (because it has to "borrow" their state), or as a singleton object that aggregates state.
Sometimes functions are just naturally static, they have no state aside from the parameterization, so they don't need to be part of an object. It's still better to leave them as functions rather than bound together in an object, because as your code evolves, it will be easier to migrate them.
In addition to what @AGC said, if the doSomething() belongs to say, a customer class, then you don't want to make that static. In other words, business classes are seldom made into static classes since their data is supposed to change in the scope of a single transaction and you don't want to keep them around all the time. Static type classes are good for long lived data and utility/helper methods. If you are using automatic testing tools, then statics may cause problems: ref1
If you really, really sure that doSomething will never ever need different implementations depending on the context (e.g. for testing), make it static, which gives you a utility class like java.lang.Math.
Using a singleton is considered more and more a bad idea: If it is possible that you need different implementations later, you should better use the factory pattern: The factory returns an implementation for an interface that defines doSomething.
The best solution in my opinion is using a dependency injection framework, which goes one step further than a factory by doing all the initialization in the background. E.g. using Google Guice you could write something like
public interface DoIt {
void doSomething(Blubb blubb);
}
class User {
@Inject DoIt doit; //injected by the DI framework
public void process() {
Blubb blubb = new Blubb();
doit.doSomething(blubb);
}
}
Of course you need to have some DoIt implementation, and you need to configure your "bindings" in the background, but the important point is that User doesn't know which DoIt was used or if it is a singleton or not. It is completely decoupled from such setup details, which can be changed without touching anything in User.
