Pros and Cons of Static Methods

[Axehelm]

Okay, I'm in a debate over whether or not static methods are a good idea in
a general domain class.

I'm personally not a fan of static methods but we seem to be using them to
load an object. For example if you have an Employee class rather then
instantiating an instance you call a static method 'GetEmployees' and it
returns a List of Employee objects.

I'm looking for what other people are doing and if you feel this is a good
or bad idea.

Thanks

[perry anderson]

Re: Pros and Cons of Static Methods

things are done differently in Java than C++, you are in more of truely
object-oriented world and thats not just a cute term. static methods are
really class messages, that is, methods that act upon an entire
classification of objects not just one instance. it is an elegant means
by which to send messages to all instances or rather the class itself
and thats how you have to start thinking.

i know your sort of coming at it from an anti-global variable approach
but static methods are not the same thing. typically they do not create
the same hang ups as global methods used in non object-oriented languages.

i could say more but first let me hear back if you understand what i am
saying

thanks

- perry


Axehelm wrote:[color=blue]
> Okay, I'm in a debate over whether or not static methods are a good idea in
> a general domain class.
>
> I'm personally not a fan of static methods but we seem to be using them to
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.
>
> Thanks
>
>[/color]

[Axehelm]

Re: Pros and Cons of Static Methods

Yes I understand what you are saying and yes I'm ant-global... :)

It just goes against what I've been taught about OO. For example a static
method cannot be overridden... correct? That seems to go against
polymorphism. Exposing multiple static methods in place of constructors
seems a bit unOO if you will to me.

"perry anderson" <perry@cplusplu s.org> wrote in message
news:xz9tc.3097 7$sr3.877804@ne ws20.bellglobal .com...[color=blue]
> things are done differently in Java than C++, you are in more of truely
> object-oriented world and thats not just a cute term. static methods are
> really class messages, that is, methods that act upon an entire
> classification of objects not just one instance. it is an elegant means
> by which to send messages to all instances or rather the class itself
> and thats how you have to start thinking.
>
> i know your sort of coming at it from an anti-global variable approach
> but static methods are not the same thing. typically they do not create
> the same hang ups as global methods used in non object-oriented languages.
>
> i could say more but first let me hear back if you understand what i am
> saying
>
> thanks
>
> - perry
>
>
> Axehelm wrote:[color=green]
> > Okay, I'm in a debate over whether or not static methods are a good idea[/color][/color]
in[color=blue][color=green]
> > a general domain class.
> >
> > I'm personally not a fan of static methods but we seem to be using them[/color][/color]
to[color=blue][color=green]
> > load an object. For example if you have an Employee class rather then
> > instantiating an instance you call a static method 'GetEmployees' and it
> > returns a List of Employee objects.
> >
> > I'm looking for what other people are doing and if you feel this is a[/color][/color]
good[color=blue][color=green]
> > or bad idea.
> >
> > Thanks
> >
> >[/color]
>[/color]

[Silvio Bierman]

Re: Pros and Cons of Static Methods


"Axehelm" <axehelm@mchsi. com> wrote in message
news:F3atc.1157 1$eT4.650@attbi _s54...[color=blue]
> Yes I understand what you are saying and yes I'm ant-global... :)
>
> It just goes against what I've been taught about OO. For example a static
> method cannot be overridden... correct? That seems to go against
> polymorphism. Exposing multiple static methods in place of constructors
> seems a bit unOO if you will to me.
>
> "perry anderson" <perry@cplusplu s.org> wrote in message
> news:xz9tc.3097 7$sr3.877804@ne ws20.bellglobal .com...[color=green]
> > things are done differently in Java than C++, you are in more of truely
> > object-oriented world and thats not just a cute term. static methods are
> > really class messages, that is, methods that act upon an entire
> > classification of objects not just one instance. it is an elegant means
> > by which to send messages to all instances or rather the class itself
> > and thats how you have to start thinking.
> >
> > i know your sort of coming at it from an anti-global variable approach
> > but static methods are not the same thing. typically they do not create
> > the same hang ups as global methods used in non object-oriented[/color][/color]
languages.[color=blue][color=green]
> >
> > i could say more but first let me hear back if you understand what i am
> > saying
> >
> > thanks
> >
> > - perry
> >
> >
> > Axehelm wrote:[color=darkred]
> > > Okay, I'm in a debate over whether or not static methods are a good[/color][/color][/color]
idea[color=blue]
> in[color=green][color=darkred]
> > > a general domain class.
> > >
> > > I'm personally not a fan of static methods but we seem to be using[/color][/color][/color]
them[color=blue]
> to[color=green][color=darkred]
> > > load an object. For example if you have an Employee class rather then
> > > instantiating an instance you call a static method 'GetEmployees' and[/color][/color][/color]
it[color=blue][color=green][color=darkred]
> > > returns a List of Employee objects.
> > >
> > > I'm looking for what other people are doing and if you feel this is a[/color][/color]
> good[color=green][color=darkred]
> > > or bad idea.
> > >
> > > Thanks
> > >
> > >[/color]
> >[/color]
>
>[/color]

You are completely right. Static methods are what the OO-purists came up
with when they discovered that there are actually good reasons for having
non-class-member functions a-la C++ (which BTW also has static methods). The
static void main stuff is the most prominent example of that.

Static methods are usefull because they give you an escape of the
everything-is-or-should-be-an-object concept. There is nothing wrong with
using them as long as you know how to.

Silvio Bierman

[Chris]

Re: Pros and Cons of Static Methods

> It just goes against what I've been taught about OO. For example a static[color=blue]
> method cannot be overridden... correct? That seems to go against
> polymorphism. Exposing multiple static methods in place of constructors
> seems a bit unOO if you will to me.[/color]

You've picked on a classic issue that I personally have never found an
answer to one way or the other.

As an example - which of these is best (using your example):

class Employee
{
...
public static Collection getAllEmployees () { ... }
}

Collection allEmployees = Employee.getAll Employees();

or:

class Employee { ... }

class EmployeeMainten ance // or some such name
{
public Collection getAllEmployees () { ... }
}

EmployeeMainten ance em = new EmployeeMainten ance();
Collection allEmployees = em.getAllEmploy ees();

Hard to say really IMHO.

If there was just one or two static methods on a class then I'd say
the first because it's easier to maintain. If the 'maintenance' class
expanded to many methods (searches, CRUD stuff, etc) then a separate
class is probably better for cohesion reasons.

As to whether static methods are not OO or not, I don't know, it's
probably only of interest to academics.

- sarge

[Ryan Stewart]

Re: Pros and Cons of Static Methods

"Chris" <sarge_chris@ho tmail.com> wrote in message
news:568394b1.0 405270304.56b98 7cf@posting.goo gle.com...[color=blue][color=green]
> > It just goes against what I've been taught about OO. For example a[/color][/color]
static[color=blue][color=green]
> > method cannot be overridden... correct? That seems to go against
> > polymorphism. Exposing multiple static methods in place of constructors
> > seems a bit unOO if you will to me.[/color]
>
> You've picked on a classic issue that I personally have never found an
> answer to one way or the other.
>
> As an example - which of these is best (using your example):
>
> class Employee
> {
> ...
> public static Collection getAllEmployees () { ... }
> }
>
> Collection allEmployees = Employee.getAll Employees();
>[/color]
Redundant naming. Try Employee.getAll ().
[color=blue]
> or:
>
> class Employee { ... }
>
> class EmployeeMainten ance // or some such name
> {
> public Collection getAllEmployees () { ... }
> }
>
> EmployeeMainten ance em = new EmployeeMainten ance();
> Collection allEmployees = em.getAllEmploy ees();
>[/color]
What's an "employee maintenance"? OOD is about modelling real world objects.
It sounds like you're still thinking procedurally.
[color=blue]
> Hard to say really IMHO.
>[/color]
Not hard for me. In the latter example, how many of the "employee
maintenance" objects are necessary? You should only ever need one, correct?
Allowing more than one to be instantiated is inefficient. So you have a
couple of options: make the methods static and give it a private constructor
or implement the Singleton pattern, which also involves a static method.
Whichever way you go, static methods are your best option.
[color=blue]
> If there was just one or two static methods on a class then I'd say
> the first because it's easier to maintain. If the 'maintenance' class
> expanded to many methods (searches, CRUD stuff, etc) then a separate
> class is probably better for cohesion reasons.
>[/color]
Cohesion? That's no OOD term I've heard of.

[kevinc]

Re: Pros and Cons of Static Methods

Classes were not meant to become repositories for functions.
Using static methods. What you in fact have, is a function.

perry anderson wrote:[color=blue]
> things are done differently in Java than C++, you are in more of truely
> object-oriented world and thats not just a cute term. static methods are
> really class messages, that is, methods that act upon an entire
> classification of objects not just one instance. it is an elegant means
> by which to send messages to all instances or rather the class itself
> and thats how you have to start thinking.
>
> i know your sort of coming at it from an anti-global variable approach
> but static methods are not the same thing. typically they do not create
> the same hang ups as global methods used in non object-oriented languages.
>
> i could say more but first let me hear back if you understand what i am
> saying
>
> thanks
>
> - perry
>
>
> Axehelm wrote:
>[color=green]
>> Okay, I'm in a debate over whether or not static methods are a good
>> idea in
>> a general domain class.
>>
>> I'm personally not a fan of static methods but we seem to be using
>> them to
>> load an object. For example if you have an Employee class rather then
>> instantiating an instance you call a static method 'GetEmployees' and it
>> returns a List of Employee objects.
>>
>> I'm looking for what other people are doing and if you feel this is a
>> good
>> or bad idea.
>>
>> Thanks
>>
>>[/color]
>[/color]

[Björn]

Re: Pros and Cons of Static Methods

Silvio Bierman wrote:
[color=blue][color=green]
>>[/color]
>
> You are completely right. Static methods are what the OO-purists came up
> with when they discovered that there are actually good reasons for having
> non-class-member functions a-la C++ (which BTW also has static methods). The
> static void main stuff is the most prominent example of that.
>
> Static methods are usefull because they give you an escape of the
> everything-is-or-should-be-an-object concept. There is nothing wrong with
> using them as long as you know how to.[/color]
Class methods doesn't need to be an escape from the pure oo concept.
Look at for instance Smalltalk where you have class methods (a kind of
static). The classes themselves are instances of meta classes therefore
the "static" methods are just ordinary methods with the full inheritance
scheme (with abilities to override and call superclass's version of the
class method).
Smalltalk does not have an "operator" new, and therefore there isn't any
need for constructors either, so to instantiate a Smalltalk object one
has to send a message to the intended class. Very often one uses the
message new; like in Set new, where the message new is sent to the class
Set; but it is not uncommon to use other class methods to instantiate
like in Circle center: 10@10 radius: 45.

By using class methods to create new instances one directly exploit the
well know Abstract Factory pattern.
E.g. Filename named: 'test.text' gives and instance of NTFSFilename on a
Windows XP platform and MacOSXFilename on a Mac OS 10 platform, etc.
That is it is possible to hide platform specific details and
instantiations from the application programmer. And thereby, among other
things, one get more portable code.


Björn

[Chris]

Re: Pros and Cons of Static Methods

I hadn't meant the code examples to be examples of good practice, just
illustrating the point.

I'm surprised you've never heard the term 'cohesion', as most of the
books and articles I read are riddled with it - maybe I'm reading the
wrong stuff.

- sarge

[Alex Kay]

Re: Pros and Cons of Static Methods

> I'm personally not a fan of static methods but we seem to be using them to[color=blue]
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.[/color]

Hi,

IN A NUTSHELL
I know what you mean but the scenario your describe is pretty normal and ok.

That type of constructor is called a "static factory", in some circumstances
they are actually preferable. Sun use them quite a bit in Java itself.
Things like Xyz.getInstance (); Of course like everything else they need to
be used wisely.

MORE DETAILS
Pros of construction using static factory methods:
Generally you get more control and flexibility.

1. Regular constructors will create an object every time they are invoked
and only when they are invoked, but with a static factory you can have
pre-built objects. Sometimes this flexibility of *when* things are really
built is highly desirable.

2. Or you can defer real construction until the object is actually used
a.k.a lazy instantiation.
static private Blah blah;
static public Blah createBlah() {
if(blah==null)
blah= new Blah();
return blah;
}
This is good for "expensive" objects, they only get created if/when they
are used.

3. Can return any type.
eg return Collection of Whatever's
Your GetEmployees() is a good example.

4. static factory's can have meaningful names, this can be good
Whatever.create AllShoppingTrol leys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGiz mo() could be a constructor but with that kind of name
you'd never know.

2. You cannot subclass (or extend) a class which only has static factory
constructors. You must use containment rather than inheritance.


Hope that helps?
Alex K

[Alex Kay]

Re: Pros and Cons of Static Methods

> I'm personally not a fan of static methods but we seem to be using them to[color=blue]
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.[/color]

Hi,

IN A NUTSHELL
I know what you mean but the scenario your describe is pretty normal and ok.

That type of constructor is called a "static factory", in some circumstances
they are actually preferable. Sun use them quite a bit in Java itself.
Things like Xyz.getInstance (); Of course like everything else they need to
be used wisely.

MORE DETAILS
Pros of construction using static factory methods:
Generally you get more control and flexibility.

1. Regular constructors will create an object every time they are invoked
and only when they are invoked, but with a static factory you can have
pre-built objects. Sometimes this flexibility of *when* things are really
built is highly desirable.

2. Or you can defer real construction until the object is actually used
a.k.a lazy instantiation.
static private Blah blah;
static public Blah createBlah() {
if(blah==null)
blah= new Blah();
return blah;
}
This is good for "expensive" objects, they only get created if/when they
are used.

3. Can return any type.
eg return Collection of Whatever's
Your GetEmployees() is a good example.

4. static factory's can have meaningful names, this can be good
Whatever.create AllShoppingTrol leys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGiz mo() could be a constructor but with that kind of name
you'd never know.

2. You cannot subclass (or extend) a class which only has static factory
constructors. You must use containment rather than inheritance.


Hope that helps?
Alex K

[Alex Kay]

Re: Pros and Cons of Static Methods

> I'm personally not a fan of static methods but we seem to be using them to[color=blue]
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.[/color]

Hi,

IN A NUTSHELL
I know what you mean but the scenario your describe is pretty normal and ok.

That type of constructor is called a "static factory", in some circumstances
they are actually preferable. Sun use them quite a bit in Java itself.
Things like Xyz.getInstance (); Of course like everything else they need to
be used wisely.

MORE DETAILS
Pros of construction using static factory methods:
Generally you get more control and flexibility.

1. Regular constructors will create an object every time they are invoked
and only when they are invoked, but with a static factory you can have
pre-built objects. Sometimes this flexibility of *when* things are really
built is highly desirable.

2. Or you can defer real construction until the object is actually used
a.k.a lazy instantiation.
static private Blah blah;
static public Blah createBlah() {
if(blah==null)
blah= new Blah();
return blah;
}
This is good for "expensive" objects, they only get created if/when they
are used.

3. Can return any type.
eg return Collection of Whatever's
Your GetEmployees() is a good example.

4. static factory's can have meaningful names, this can be good
Whatever.create AllShoppingTrol leys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGiz mo() could be a constructor but with that kind of name
you'd never know.

2. You cannot subclass (or extend) a class which only has static factory
constructors. You must use containment rather than inheritance.


Hope that helps?
Alex K

[Alex Kay]

Re: Pros and Cons of Static Methods

> I'm personally not a fan of static methods but we seem to be using them to[color=blue]
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.[/color]

Hi,

IN A NUTSHELL
I know what you mean but the scenario your describe is pretty normal and ok.

That type of constructor is called a "static factory", in some circumstances
they are actually preferable. Sun use them quite a bit in Java itself.
Things like Xyz.getInstance (); Of course like everything else they need to
be used wisely.

MORE DETAILS
Pros of construction using static factory methods:
Generally you get more control and flexibility.

1. Regular constructors will create an object every time they are invoked
and only when they are invoked, but with a static factory you can have
pre-built objects. Sometimes this flexibility of *when* things are really
built is highly desirable.

2. Or you can defer real construction until the object is actually used
a.k.a lazy instantiation.
static private Blah blah;
static public Blah createBlah() {
if(blah==null)
blah= new Blah();
return blah;
}
This is good for "expensive" objects, they only get created if/when they
are used.

3. Can return any type.
eg return Collection of Whatever's
Your GetEmployees() is a good example.

4. static factory's can have meaningful names, this can be good
Whatever.create AllShoppingTrol leys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGiz mo() could be a constructor but with that kind of name
you'd never know.

2. You cannot subclass (or extend) a class which only has static factory
constructors. You must use containment rather than inheritance.


Hope that helps?
Alex K

[Hal Rosser]

Re: Pros and Cons of Static Methods

Use each when warranted.
For instance, in a class 'Person';;; fields like name, address, height,
weight should be instance vars, but it would make sense for personCount (the
number of "Person' objects instantiated) to be static - it belongs to the
class along with the set/get methods for it.


"Axehelm" <axehelm@mchsi. com> wrote in message
news:KI8tc.2898 8$af3.1594862@a ttbi_s51...[color=blue]
> Okay, I'm in a debate over whether or not static methods are a good idea[/color]
in[color=blue]
> a general domain class.
>
> I'm personally not a fan of static methods but we seem to be using them to
> load an object. For example if you have an Employee class rather then
> instantiating an instance you call a static method 'GetEmployees' and it
> returns a List of Employee objects.
>
> I'm looking for what other people are doing and if you feel this is a good
> or bad idea.
>
> Thanks
>
>[/color]


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.690 / Virus Database: 451 - Release Date: 5/22/2004