When i want to use a static method?

  • Thread starter Thread starter Fernando Lopes
  • Start date Start date
F

Fernando Lopes

Hi there!
Someone has some code sample about when is recommend use a statis method?
I know this methos don't want to be initialized and all but I want to know
when I need to use it.

Tks.
Fernando
 
I use static methods when I need to get something that is relevant to
that class but I don't want to create an instance everytime to get this
information. With a static method you cannot access
methods/properties/variables from the class. The only variables
available are within the static method you are calling.
 
Typically Helper and Utility methods are good candidates. Often times as
well, you may want to create Static as well as instance objects. Looking to
the framewokr, there's the File and the FileInfo, the Directory and
directoryInfo. Similarly, check out the Data Access Application Block - all
of the SqlHelper methods are static - and as a rule of thumb, anything you'd
name xxxHelper usually is a great candidate for being implemented as a
static.
 
I think that you should also make a distinction between when to create
_public_ static methods, and when to create _private_ static methods.

All of the information given here so far is valid for public static
methods. If your class is exporting a static method, it's usually
because it's functionality that belongs with your class, but for which
you don't want your callers to have to create an object just to use it.
For example, most Parse methods are static, because you don't want your
caller to have to create a throw-away object just to parse a string to
make the object they really want. To illustrate:

MyClass parsedObject = MyClass.Parse(inputString);

is better than

MyClass parsedObject = new MyClass().Parse(inputString);

because the Parse method doesn't need anything from a particular
MyClass in order to do its job (it just needs the string), and why
should your caller create a throw-away MyClass (new MyClass()) in order
to use the method?

_Private_ static methods come with different considerations.

Whenever you make an instance private method, you're giving that method
access to all of the fields in your class. Sometimes you don't need
that. Sometimes you just need a little "helper" method that does a
small job. Rather than give it access to your class's state, you can
make it static and pass it everything it needs in order to do its job.

This is easier to read and easier to maintain. A static private method
says, "You don't need to worry that somewhere inside my code I use some
fields of this class... or, even worse, that somewhere buried in my
code I _change_ some fields in this class. The only information I need
is in my parameter list. The only information I modify is in my
parameter list and in my return value."

Not only that, but the static private method can't call any instance
methods, so it can't modify an object in any other way.

In other words, static private methods come with many fewer assumptions
that private instance methods. For that reason they're attractive.
However, if you have to pass a dozen fields to a private static method,
then it should probably be an instance method. There's a balance to be
struck: if an instance method needs only one or two instance fields,
consider making it static. If a static method needs a dozen instance
fields passed to it, consider making it an instance method.
 
DKode said:
I use static methods when I need to get something that is relevant to
that class but I don't want to create an instance everytime to get this
information. With a static method you cannot access
methods/properties/variables from the class. The only variables
available are within the static method you are calling.
Click to expand...
Not quite right, you can also access static class variables (and consts) or
static properties
 
I know this methos don't want to be initialized

All methods are static in a sense - even instance methods. The logic of
instance methods does not get copied every time an instance of its class is
created, it lives in one place and a pointer to the instance is passed to
that method - that's what the "this" pointer is, it's just done for you.

Basically what happens is that the compiler sticks a pointer to an instance
of the class as the first argument. So for class Foo, you define a method:

int Bar(int i) { return(this.x + i); }

and the compiler turns it into this:

int Bar(Foo f, int i) { return(f.x + i); }

If a copy of each method was made for each object allocation there would be
huge and unnecessary overhead; think of a class like String with a ton of
methods being copied all over the place all the time.
 
Bruce Wood said:
This is easier to read and easier to maintain. A static private method
says, "You don't need to worry that somewhere inside my code I use some
fields of this class... or, even worse, that somewhere buried in my
code I _change_ some fields in this class. The only information I need
is in my parameter list. The only information I modify is in my
parameter list and in my return value."
Click to expand...

Unless there are static fields in the class of course - and a static
method can call private methods (or modifiy private fields) on any
instances of the class it's able to get hold of (whether parameters,
static fields or whatever).

Often it's nice to have a static method which takes two instances of
the class just because it's not specifically applicable to one instance
"more" than the other instance.
 
Unless there are static fields in the class of course - and a static
method can call private methods (or modifiy private fields) on any
instances of the class it's able to get hold of (whether parameters,
static fields or whatever).

Agreed. Nonetheless, I think it's easier to maintain a private method
that takes one or two extra arguments and is static than a private
instance method that uses only one or two instance fields, because you
don't really know what the latter is doing without examining the code.
 
Back
Top