By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,779 Members | 1,078 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,779 IT Pros & Developers. It's quick & easy.

Pros and Cons of Static Methods

P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
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:
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


Jul 17 '05 #2

P: n/a
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" <pe***@cplusplus.org> wrote in message
news:xz********************@news20.bellglobal.com. ..
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:
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

Jul 17 '05 #3

P: n/a

"Axehelm" <ax*****@mchsi.com> wrote in message
news:F3atc.11571$eT4.650@attbi_s54...
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" <pe***@cplusplus.org> wrote in message
news:xz********************@news20.bellglobal.com. ..
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:
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



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
Jul 17 '05 #4

P: n/a
> 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.


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.getAllEmployees();

or:

class Employee { ... }

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

EmployeeMaintenance em = new EmployeeMaintenance();
Collection allEmployees = em.getAllEmployees();

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
Jul 17 '05 #5

P: n/a
"Chris" <sa*********@hotmail.com> wrote in message
news:56**************************@posting.google.c om...
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.
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.getAllEmployees();

Redundant naming. Try Employee.getAll().
or:

class Employee { ... }

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

EmployeeMaintenance em = new EmployeeMaintenance();
Collection allEmployees = em.getAllEmployees();
What's an "employee maintenance"? OOD is about modelling real world objects.
It sounds like you're still thinking procedurally.
Hard to say really IMHO.
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.
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.

Cohesion? That's no OOD term I've heard of.
Jul 17 '05 #6

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

perry anderson wrote:
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:
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


Jul 17 '05 #7

P: n/a
Silvio Bierman wrote:


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.

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
Jul 17 '05 #8

P: n/a
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
Jul 17 '05 #9

P: n/a
> 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.


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.createAllShoppingTrolleys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGizmo() 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

Jul 17 '05 #10

P: n/a
> 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.


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.createAllShoppingTrolleys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGizmo() 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

Jul 17 '05 #11

P: n/a
> 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.


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.createAllShoppingTrolleys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGizmo() 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

Jul 17 '05 #12

P: n/a
> 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.


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.createAllShoppingTrolleys()

Cons:
1. Poor naming conventions can make it hard to know that is going on
eg Whatever.getGizmo() 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

Jul 17 '05 #13

P: n/a
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" <ax*****@mchsi.com> wrote in message
news:KI8tc.28988$af3.1594862@attbi_s51...
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

---
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
Jul 17 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.