 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2007applicability of static methods in web applications?
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, > For my project, I see that some people use static methods for the [quoted text clipped - 15 lines] > > 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) > > Hi, > > For my project, I see that some people use static methods for the [quoted text clipped - 26 lines] > 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? > 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 > 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". > For my project, I see that some people use static methods for the > web-application in DB layer. [quoted text clipped - 7 lines] > 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 >> public static List getId(){ >> return list; [quoted text clipped - 4 lines] > > 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 >>> public static List getId(){ >>> return list; [quoted text clipped - 13 lines] > > 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 >>>> public static List getId(){ >>>> return list; [quoted text clipped - 23 lines] > > 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. > Things are working at our end (though it might be absurd). The variables > declared in static method fall under thread scope right?. The DB [quoted text clipped - 16 lines] > ----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 > Things are working at our end (though it might be absurd). The variables > declared in static method fall under thread scope right?. The DB [quoted text clipped - 16 lines] > ----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 >> Things are working at our end (though it might be absurd). The >> variables declared in static method fall under thread scope right?. [quoted text clipped - 29 lines] > > 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. >> That use of static is fine. >> [quoted text clipped - 13 lines] > 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 > Hi, > For my project, I see that some people use static methods for the [quoted text clipped - 15 lines] > > 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. - 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, [quoted text clipped - 7 lines] > 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?  SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.