instance vs. static question

[allison]

Can someone point me to a guide on when to use static methods versus
instance methods in a class? For instance, is it bad design to have a
static method that creates an instance of another class? I am looking for a
good explanation.

Thanks in advance

[Bjorn Abelli]

"allison" wrote...

Can someone point me to a guide on when
to use static methods versus
instance methods in a class?
The simplest guide is to

- use instance methods when it's implementation
is depending on attributes, properties or
other instance methods for the instance itself.

- use static methods in every other case
For instance, is it bad design to have a
static method that creates an instance of
another class?

That depends...

If the method doesn't need any characteristics from the instance, that
method could very well be static.

On the other hand, there could possibly exist situations where a Singleton
pattern combined with some Factory Method pattern makes it preferable to
make it an instance method.

Hence, the answer to that question depends on what problem you're trying to
solve.

// Bjorn A

[Jens Thiel]

"Bjorn Abelli" <bj**********@DoNotSpam.hotmail.com> wrote:

The simplest guide is to

- use instance methods when it's implementation
is depending on attributes, properties or
other instance methods for the instance itself.

- or -

you want to make the method accessible by COM interop, which does not
support static methods.
Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/
Replace MSDN with my first name when replying to my email address!

[Jeff Louie]

Allison...

http://www.geocities.com/jeff_louie/OOP/oop4.htm

Static fields are useful when you want to store state related to all
instances of a class. A counter is a good example of a static field. The
classic use of a static counter is to generate a unique ID or serial
number
for each instance of a class.*

Static methods are useful when you have behavior that is global to the
class and not specific to an instance of a class. In contrast, instance
methods are useful when the method needs to know about the state of
an object. Since data and behavior are intertwined in an object,
instance
methods have access to the instance fields and can exhibit behavior that
is specific to the state of an object.

A static method that creates an instance is an example of a class
factory.

Regards,
Jeff

Can someone point me to a guide on when to use static methods

versuinstance methods in a class? For instance, is it bad design to have
a
static method that creates an instance of another class<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Davis]

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...

"Bjorn Abelli" <bj**********@DoNotSpam.hotmail.com> wrote:

The simplest guide is to

- use instance methods when it's implementation
is depending on attributes, properties or
other instance methods for the instance itself.

- or -

you want to make the method accessible by COM interop, which does not
support static methods.
Jens.

That's a situation in itself. Good note though.

Jon

[Jon Davis]

"allison" <nospam> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Can someone point me to a guide on when to use static methods versus
instance methods in a class? For instance, is it bad design to have a
static method that creates an instance of another class? I am looking for a good explanation.

Thanks in advance

Generally speaking, OOP purists tend to frown upon static methods unless
it's necessary, such as when there could not possibly be any way to have
instance state information or instance-specific methods to be called. On the
other hand, there are some cases when instantiating a class is a nuisance,
and making the methods non-static would make the task unnecessarily
non-trivial. The static methods of System.IO.File and System.IO.Directory
are good examples of this ... These could have been designed such that one
would have to create a Directory object (passing the path into a constructor
as a string) before you can get its files or access its other properties /
methods, but it made more sense from a design perspective -- that is, there
proved to be no otherwise advantage for developers, the users of the .NET
Framework -- to keep the methods static.

So, the long and short of it is, it really just depends. Ask yourself if
there could possibily be any need to instantiate an object. If not, don't
bother. Make it static. However, typically such instances should be far less
often than non-static, for the sake of OOP.

Jon