applicability of static methods in web applications?

[vishist]

Hi,
For my project, I see that some people use static methods for the
web-application in DB layer.

eg:

public static List getId(){
return list;
}

Now, I know that this method works in a threaded environment since all
these methods fall in thread scope. But coding like this defeats the
whole purpose of choosing a object oriented language. I'm confused
here whether it is a good style or not.

You comments are really appreciated..

V.

 

[Daniel Pitts]

Hi,
For my project, I see that some people use static methods for the
web-application in DB layer.

eg:

public static List getId(){
return list;

}

Now, I know that this method works in a threaded environment since all
these methods fall in thread scope. But coding like this defeats the
whole purpose of choosing a object oriented language. I'm confused
here whether it is a good style or not.

You comments are really appreciated..

V.

I personally think its quite bad style. There are, however, some
limitations with standard servlets, it is often easier to have static
utility methods.

I've actually gone as far personally to create a wrapper object when
contains a request, and all sorts of other information, and have that
object handle the business logic. Only in a couple Tag classes (where
its unavoidable) do I access anything static or at an application
scope. and in those cases its usually to access a factory object
which has been configured through Spring (IoC is the way to be)

 

[vishist]

I personally think its quite bad style. There are, however, some
limitations with standard servlets, it is often easier to have static
utility methods.

I've actually gone as far personally to create a wrapper object when
contains a request, and all sorts of other information, and have that
object handle the business logic. Only in a couple Tag classes (where
its unavoidable) do I access anything static or at an application
scope. and in those cases its usually to access a factory object
which has been configured through Spring (IoC is the way to be)

Hi,
Thanks for responding to my request.
When you say personally, isn't there any steadfast rule that says you
shouldn't create static methods that has business logic in them?.
Also, when you say limitations with standard servlets, can you please
elaborate on them? I mean I want to understand your perspective.
Let me rephrase my question:
In a multi-threaded object oriented programming, is it wise to have
static methods with business logic embedded in them?

 

[Chris Uppal]

Let me rephrase my question:
In a multi-threaded object oriented programming, is it wise to have
static methods with business logic embedded in them?

I think that can be answered quite simply: no.

Static methods in general have many "bad" features: they introduce excessive
coupling, they make the system inflexible, they are hostile to certain testing
methodologies. Perhaps more importantly they have nothing whatever to do with
OO programming (and if you don't think that OO programming is an advantage for
the application you are writing then you are wasting your time using Java at
all).

That's not to say that you should avoid static methods entirely -- they have
their place in any reasonable design. But you should regard each static method
with suspicion, and ask yourself "what am I /really/ trying to do here ?"
Static methods are useful in implementing various kinds of glue (to allow one
part of a system to find another part of a system), but they are never the
/only/ way of implementing that glue, and sometimes they are not the /best/ way
of doing it. Static methods can also be useful for helper/utility methods of
various kinds (consider the static methods on java.util.Arrays, for instance),
but again they are not necessarily the /best/ way of packaging utility code. I
don't usually like absolutes in programming or design ("never do XYZ" or
"always do XYZ") but on this subject I feel safe in sticking my neck out and
stating that "real" logic should never be implemented in static methods.

(All the above applies regardless of whether you are working in a Servlet-style
context).

-- chris

 

[Tom Hawtin]

Static methods in general have many "bad" features: they introduce excessive
coupling, they make the system inflexible, they are hostile to certain testing
methodologies. Perhaps more importantly they have nothing whatever to do with
OO programming (and if you don't think that OO programming is an advantage for
the application you are writing then you are wasting your time using Java at
all).

I would be very wary about making a method non-static just on the basis
of principle. You[1] may be coupling the method to a particular object
for no specific purpose. When you do find that the method just become an
instance method, then there is no reason to suspect that you put it on
the right object. So then it's a case of disentangling the method before
you can re-entangle it.

Therefore, I suggest prefer static methods "all other things being
equal" (which they probably wont be).

But not static variables. Static variables are evil.

Tom Hawtin

[1] My usual "indefinite you".

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

For my project, I see that some people use static methods for the
web-application in DB layer.

eg:

public static List getId(){
return list;
}

Now, I know that this method works in a threaded environment since all
these methods fall in thread scope.

That code looks very thread unsafe to me.

Arne

 

[Tom Hawtin]

That code looks very thread unsafe to me.

You can't tell from a fragment.

private static final List list =
Collections.unmodifiableList(Arrays.asList(new String[] {
"A", "B", "C"
}));

private static final List list = new Vector();

Tom Hawtin

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That code looks very thread unsafe to me.

You can't tell from a fragment.

private static final List list =
Collections.unmodifiableList(Arrays.asList(new String[] {
"A", "B", "C"
}));

private static final List list = new Vector();

The original post stated that the code was in DB layer.

A static method returning a static field in a DB layer
does look thread unsafe.

It is possible to create absurd examples where it is
not, but I do not see much point in that.

Arne

 

[vishist]

vishist wrote:

public static List getId(){
return list;
}

Now, I know that this method works in a threaded environment since all
these methods fall in thread scope.

That code looks very thread unsafe to me.

You can't tell from a fragment.

private static final List list =
Collections.unmodifiableList(Arrays.asList(new String[] {
"A", "B", "C"
}));

private static final List list = new Vector();

The original post stated that the code was in DB layer.

A static method returning a static field in a DB layer
does look thread unsafe.

It is possible to create absurd examples where it is
not, but I do not see much point in that.

Arne

I've been following newgroups recently and never knew that there will be
responses to my question after couple of days. I'm sorry.

Now, to Arne's comment,
Things are working at our end (though it might be absurd). The variables
declared in static method fall under thread scope right?. The DB
Connection, statement, resultset all fall in the same static method.

public static List getMyResultSet(){
Connection conn = getConnection();
PreparedStatement pStatement = conn.prepareStatement();
ResultSet rSet = pStatement.executeQuery();
List resultSetObjectList = new ArrayList();
...................
...................//Populating resultSetObjectList here
...................
return resultSetObjectList;
}

this is how our code is written and is working now. We invoke these
methods statically from the servlet prefixing the Class name. I know
that this is not a good style. Infact that was my question:
----isn't there any steadfast rule that says you shouldn't create static
methods that has business logic in them?.

Please comment!

vishist.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Things are working at our end (though it might be absurd). The variables
declared in static method fall under thread scope right?. The DB
Connection, statement, resultset all fall in the same static method.

public static List getMyResultSet(){
Connection conn = getConnection();
PreparedStatement pStatement = conn.prepareStatement();
ResultSet rSet = pStatement.executeQuery();
List resultSetObjectList = new ArrayList();
...................
...................//Populating resultSetObjectList here
...................
return resultSetObjectList;
}

this is how our code is written and is working now. We invoke these
methods statically from the servlet prefixing the Class name. I know
that this is not a good style. Infact that was my question:
----isn't there any steadfast rule that says you shouldn't create static
methods that has business logic in them?.

There are no problems with that code.

The code you posted was:

public static List getId(){
return list;
}

which looked as if list was a static field.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Things are working at our end (though it might be absurd). The variables
declared in static method fall under thread scope right?. The DB
Connection, statement, resultset all fall in the same static method.

public static List getMyResultSet(){
Connection conn = getConnection();
PreparedStatement pStatement = conn.prepareStatement();
ResultSet rSet = pStatement.executeQuery();
List resultSetObjectList = new ArrayList();
...................
...................//Populating resultSetObjectList here
...................
return resultSetObjectList;
}

this is how our code is written and is working now. We invoke these
methods statically from the servlet prefixing the Class name. I know
that this is not a good style. Infact that was my question:
----isn't there any steadfast rule that says you shouldn't create static
methods that has business logic in them?.

That use of static is fine.

I am no aware of any rule that prohibits business logic
in static methods.

But even if there were then the code above is not business
logic !

The code is very similar to code in MS DAAB.

Arne

 

[vishist]

That use of static is fine.

I am no aware of any rule that prohibits business logic
in static methods.

But even if there were then the code above is not business
logic !

The code is very similar to code in MS DAAB.

Arne

The thing is that as the past posts explain, they are introducing kind
of tight coupling across the system. Now, I saw another application that
they are using patterns to get an instance of the object and then use it
to save/update/delete in the client object. I know that its a personal
flavor thing to choose the path of implementation. But then when so much
is going on Patterns, abstractness why is that its being implemented
like this? Is there any good reason for this?

vishist.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

The thing is that as the past posts explain, they are introducing kind
of tight coupling across the system. Now, I saw another application that
they are using patterns to get an instance of the object and then use it
to save/update/delete in the client object. I know that its a personal
flavor thing to choose the path of implementation. But then when so much
is going on Patterns, abstractness why is that its being implemented
like this? Is there any good reason for this?

If you create:
- an interface
- a factory with a method that returns an implementation
of that interface

Then you can replace the implementation without code change
in the rest of the app.

But you will still have a static method in the factory.

And because JDBC already to some extent encapsulate the
choice of database, then it is not so obvious what you gain.

If you need something more encapsulated than your
class, then I think you should go for an external
persistence framework (Hibernate or one of the many
other).

Arne

 

[pacleb]

Hi,
For my project, I see that some people use static methods for the
web-application in DB layer.

eg:

public static List getId(){
return list;

}

Now, I know that this method works in a threaded environment since all
these methods fall in thread scope. But coding like this defeats the
whole purpose of choosing a object oriented language. I'm confused
here whether it is a good style or not.

You comments are really appreciated..

V.

Hi All, I'm experiencing a major issue with my web app. When there
are 2 or more users using the app, data swapping occurs -- that is,
when User A and User B is using the system at the same time,
sometimes, User A can see data of User B.

As of now, I haven't found out the exact scenario in which I can
reproduce this issue. Without knowing how to test it, I can't fix it.

Since I can't fix it, I just look at the code for now. I'm having
thoughts that the swapping occurs because the code uses a static
method in retrieving data from the database.

I'm not sure of this. But any insight of what I said above would be
really helpful.

 

[Lew]

- a completely unrelated thread -

Please start a new thread for a new question or topic. It's bad form to
follow on an old thread with a new topic.

Hi All, I'm experiencing a major issue with my web app. When there
are 2 or more users using the app, data swapping occurs -- that is,
when User A and User B is using the system at the same time,
sometimes, User A can see data of User B.

As of now, I haven't found out the exact scenario in which I can
reproduce this issue. Without knowing how to test it, I can't fix it.

Since I can't fix it, I just look at the code for now. I'm having
thoughts that the swapping occurs because the code uses a static
method in retrieving data from the database.

Yep. Why does it use a static method to retrieve data? What is your code?

Send an SSCCE, otherwise we're shooting in the dark. Specifics, man, specifics.

Static method is a likely culprit, though. Again, why is it static?