File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Using too much static functions in code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Using too much static functions in code" Watch "Using too much static functions in code" New topic
Author

Using too much static functions in code

Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 378
Is it fruitful to make 6 classes and make all functions(5 function each class) static and call in 7th by class names and pass values to it?

Will it execute fast? is it better approach then to make objects of all 7?

please explain!!!


Regards
Azrael Noor
Greg Brannon
Bartender

Joined: Oct 24, 2010
Posts: 557
You didn't provide enough info.

What does fruitful mean? How is that measured?

When you say functions, do you mean methods? If so, your plan is to have 6 classes with 5 methods in each class, a total of 30 methods. In your approach, the 30 methods will be called statically by a 7th class that passes values as needed.

Will it execute fast? Again, what's fast? More importantly, what do the methods do? Estimating performance without knowing what the methods do is difficult. Perhaps you're asking if this approach will execute faster than creating instances of the 6 classes and using those instances to access their methods rather than using their methods statically. Someone here may be able to guess at relative performance of the two approaches. Again, depending on what the methods do, I suspect there won't be a noticeable difference. Coding the two approaches and comparing their performance might be an interesting experiment for you to go do.

Is the approach you outlined better than creating instances of the 6 classes? Better how? I'm sure there are reasonable arguments for both approaches.


Learning Java using Eclipse on OpenSUSE 11.2
Linux user#: 501795
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4634
    
    5

In general, it is bad design to have tons of static methods. You can run into problems with name space, and in multi-threaded usages. Plus, they make good unit testing much harder.

You can achieve the same effect with better code by having the methods be normal to an object and have a static MyClass getInstance() method.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18110
    
    8

Consider this: you just asked us if some code which hasn't been written yet will be fast. Does this not strike you as a question which is, um, not very useful?

Here's a similar question: I'm thinking of a thing. Is it big?
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 378
what do the methods do? Estimating performance without knowing what the methods do is difficult

Here's a similar question: I'm thinking of a thing. Is it big?




code is already written, i was studying that but bit confused

class a: static function contains web service call
class b: static function contain parsing of web service response - xml parsers
class c: static function contain queries to access database
class d: static function for logging etc.
class e: classname.staticfunc(param) - if return true cool else not

something like that i think now you got what is going

it is single threaded

Plus, they make good unit testing much harder.

how?



Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13868
    
  10

If you're using a lot of static methods, then you are not making use of object oriented programming. Your program will then essentially be a procedural style program, just like an old C program with only global functions.

Using static methods and singletons makes unit testing much harder because it's almost impossible to swap out components with mock components for unit testing. Suppose, for example, that you have a class named PersonDao which is a data access object to store and retrieve Person objects from a database. And suppose that you have some component in your system that uses PersonDao.

For testing that component in a unit test, you'll probably want the component to not use the real PersonDao that writes to and reads from the database, but you want to use a mock version of PersonDao, just to check if the component to test calls it properly.

If PersonDao would contain only static methods, it would be almost impossible to replace it with a mock version for testing. Your code that uses PersonDao would look like this:

What if you would want to use a MockPersonDao instead of the real PersonDao for testing? That's impossible without changing the code above.

To make the code more testable, it would be better to create a PersonDao interface, and then create a PersonDaoImpl class with the real implementation, with non-static methods. For testing you can create a MockPersonDaoImpl which also implements the interface. You could then use dependency injection to pass the appropriate PersonDao implementation to the component. For testing, you'd pass it the MockPersonDaoImpl, and for "real", the normal PersonDaoImpl.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 378
Jesper de Jong wrote:If you're using a lot of static methods, then you are not making use of object oriented programming. Your program will then essentially be a procedural style program, just like an old C program with only global functions.

Using static methods and singletons makes unit testing much harder because it's almost impossible to swap out components with mock components for unit testing. Suppose, for example, that you have a class named PersonDao which is a data access object to store and retrieve Person objects from a database. And suppose that you have some component in your system that uses PersonDao.

For testing that component in a unit test, you'll probably want the component to not use the real PersonDao that writes to and reads from the database, but you want to use a mock version of PersonDao, just to check if the component to test calls it properly.

If PersonDao would contain only static methods, it would be almost impossible to replace it with a mock version for testing. Your code that uses PersonDao would look like this:

What if you would want to use a MockPersonDao instead of the real PersonDao for testing? That's impossible without changing the code above.

To make the code more testable, it would be better to create a PersonDao interface, and then create a PersonDaoImpl class with the real implementation, with non-static methods. For testing you can create a MockPersonDaoImpl which also implements the interface. You could then use dependency injection to pass the appropriate PersonDao implementation to the component. For testing, you'd pass it the MockPersonDaoImpl, and for "real", the normal PersonDaoImpl.


Thank you for explaining

Conclude till now

1) Using Lot of Static changes do not make appropriate use of programming paradigm required.
2) Using Lot of Static Methods, can make Unit Testing Harder.
3) Using Lot of Static Methods, can create issue in Multithreading (<---- Confuse with this, in case of static methods, in case of static instance variables it would be difficult as multiple thread use same variable so value collision, but in case of sttaic methods i think we are passing different parameters everytime so it will calculatre different results)
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4634
    
    5

Azrael Noor wrote:3) Using Lot of Static Methods, can create issue in Multithreading (<---- Confuse with this, in case of static methods, in case of static instance variables it would be difficult as multiple thread use same variable so value collision, but in case of sttaic methods i think we are passing different parameters everytime so it will calculatre different results)


If the calling object passes in variables, rather than using static ones, then local variables in in instance method are already thread safe.
Plus, most servlet containers create multiple threads to handle multiple requests. So use of static values is very dangerous.

Much better to use local instance variables in real objects.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Using too much static functions in code
 
Similar Threads
advantage
Question on inheritence
Helper classes-Design question
Session Utility class
best practices min, max function?