aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Refactoring - consequences of changing methods to static Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Refactoring - consequences of changing methods to static" Watch "Refactoring - consequences of changing methods to static" New topic
Author

Refactoring - consequences of changing methods to static

Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Hi All,

I am really hoping somebody can point out any pitfalls of changing methods to static in this case.

I have to work with a module. Although, it is written in Java, it is all very procedural in structure. Every class is just a collection of methods, there are no instance variables at all. And there are JSP's that create a bean with 'page' scope and basically just call those methods passing them the required parameters.

Of course, there are a lot of things wrong with this and what I would like to do is a compelete refactoring in OO way, and separate the whole thing into multiple tiers. But that may not be possible. The programs may not be OO, but they are doing what they are supposed to do, and it would be nearly impossible to convince the bosses for a compelete refactoring. Moreover, there are no automated tests at the moment, and before doing any kind of refactoring, I will have to write tests, and again it is going to be really hard to get approval for that.

So, as a first pass on refactoring, I am considering changing the method signatures to static, and using them directly from JSP's without creating 'page' scope beans. This is far from ideal, but at least there wont be new objects created for each request, and it will remove the 'pretension' of being OO, exposing the real procedural nature of the program.Most importantly, it wont break any existing fuctionality, and can be done very quickly, over a couple of days infact.

Let me reiterate, all the methods only have local variables, no methods depend on the state of the object (since the objects do not have a state).

Is there any way I could go wrong, if I go ahead with this little exercise?
Would the performance be affected because of multiple calls on static methods as against calling the same method on an object (I dont think it would, but just in case)?

Can somebody point me to any resouces that explain where static methods are stored in memory as against the instance methods, and in what respects the JVM invocation of static methods differs from the invocation of instance methods.

Thanks,
Sonny


The future is here. It's just not evenly distributed yet. - William Gibson
Consultant @ Xebia. Sonny Gill Tweets
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I think making the methods static should work without problems.

However, I think I wouldn't invest the time to do it. After all, it doesn't buy you anything, does it? The methods not being static might even be a good first step to refactoring to a more object oriented solution (which I would only do when I had to touch the code anyway while implementing new features).


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Thanks Ilja.

I also found this by a quick google search

http://today.java.net/pub/a/today/2003/12/30/staticsSQ1.html

"well, technically, all methods are static. the class represents all methods as static methods, but the instance methods simply pass a reference to the class itself as an implied variable. So, it makes no impact on memory other than the fact that you are effectively passing one additionaly argument to your method. Its not really anything to get twisted up about."


I thought it may make a difference, since there wont be a new object created on every call to the JSP, but it appears it wont make much difference. Funny I remember knowing the above when I prepared for the Sun certification, but I hardly use static methods, and I could not figure that out. Maybe its time to pick up the old Khalid-Mugal and go through that stuff again
[ September 01, 2004: Message edited by: Sonny Gill ]
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211


[ September 01, 2004: Message edited by: Sonny Gill ]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Sonny Gill:
"well, technically, all methods are static. [...]"
That's total nonsense, depending on what you think the word "static" means. The author of this bit interprets "static" to mean "there's just one copy of the code". Well, yes, of course there is. I don't know of any language or runtime that keeps a separate copy of the code for every object! In Java, there are important differences between static and non-static methods: static methods are bound early whereas instance methods are bound late, i.e., the actual method implementation being called is determined by the runtime type of your object. If you see this as an implication of "static", the statement "all methods are technically static" is blatantly false.

This additional level of indirection in instance methods means that they are generally a little bit slower than static methods. A teensie weensie, hardly measurable little bit, but a bit.

- Peter
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Replacing a real object instance and methods with static methods may have one undesired effect: It's much harder to replace the class or override the methods. In real life I'm working with a Logger wiht static methods:

And I go along pretty happily until one day I'd like to replace that Logger with another one. Rats, the Logger class is hard coded in dozens of other classes. I can't easily reconfigure the system to use another logger. Maybe a real class & factory would help:

or maybe with an application assembler to set up the logger:

As always, the choices are endless. Hope something there rang a bell.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Yes I think that guy meant one copy of the code as he goes on to say "So, it makes no impact on memory other...." . A bit simplistic I agree.
Great explanation Peter, but coming from you that is no surprise

Thanks for the reply Stan. I agree with most of what you say. The reason I was considering this was that the whole module is basically procedural programs written in Java. There is no possibility of getting any benefits of OO programming without a total rewrite of the whole thing with an OO design.

I have decided not to do it though, unless and until the option of rewriting it comes up. As Peter, suggested it isnt worth it, that time can be spent on something more useful. Thanks for your help.

Sonny
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sonny Gill:
There is no possibility of getting any benefits of OO programming without a total rewrite of the whole thing with an OO design.


With all due respect, I don't buy that. I think virtually every system can be refactored to a better OO design in tiny, incremental steps.

Wether it's easy to see how to do it, or even worth the effort, is another question, of course...
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

You are right. Instead of 'total rewrite', I should have said a 'major rewrite'.

But it is a big shift, and I almost feel that it is nearly impossible to do it unless the bosses realize the need and support it fully. It will require them to allocate time and money for writing tests, work closely with developers to figure out how the system can be broken into small subsystems with well defined boundaries, which can then be reimplemented using OO concepts one by one, tested and integrated (or integrated in a separate branch).
And equally important, they need to reevaluate their hiring policies. There is no point I starting to write an OO system, and the next person who is given charge of it after me, finds it is too complex for him.

Having said that, I recently added a new module to the existing system. It does not interact extensively with the rest of the system, so I could write most of it in OO fashion, although I had to put in a few ugly hooks at places where it did need to work with an external subsystem.

So, at the moment I have comments like this in my code.
/* This class should be factored into other classes in a well-designed OO system */
/* added -sonny 19-05-2004 REFACTOR into **blah blah** */
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sonny Gill:
You are right. Instead of 'total rewrite', I should have said a 'major rewrite'.

But it is a big shift, and I almost feel that it is nearly impossible to do it unless the bosses realize the need and support it fully. It will require them to allocate time and money for writing tests, work closely with developers to figure out how the system can be broken into small subsystems with well defined boundaries, which can then be reimplemented using OO concepts one by one, tested and integrated (or integrated in a separate branch).


Well, I wouldn't hold my breath...

The only way I have "reworking a system" actually seen work is: with every change request you work on, make sure that the code you touch gets better than it was before. Don't accept working to deadlines that force you to let the code further degenerate.

This is something that you possibly have to do over the years, but it's worth it.

And equally important, they need to reevaluate their hiring policies. There is no point I starting to write an OO system, and the next person who is given charge of it after me, finds it is too complex for him.


In my experience, this may as well be more a problem of the working culture. In a culture where you feel encouraged to ask for help and to collaborate, this doesn't need to be a problem.

Having said that, I recently added a new module to the existing system. It does not interact extensively with the rest of the system, so I could write most of it in OO fashion, although I had to put in a few ugly hooks at places where it did need to work with an external subsystem.


Sounds like a good first step.

So, at the moment I have comments like this in my code.
/* This class should be factored into other classes in a well-designed OO system */
/* added -sonny 19-05-2004 REFACTOR into **blah blah** */


Sometimes it's also possible to write a more OO Facade for the less OO part of the system and deprecate the less OO API.

Sometimes it's simpler to refactor the less OO system, though...
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Hi!

I want to ask a little question? Have you made an analysis and found a list of benefits before starting to work on this refactoring? I agree with you that it may look ugly but sometimes it is the right way.
About this type of patterns/architectures you can further read here:
* Transaction Script
* Service Layer

./pope


blog - InfoQ.com
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

"Sometimes it's also possible to write a more OO Facade for the less OO part of the system and deprecate the less OO API."

Now, that's something I am sure I will be able to use at some stage. Thanks Ilja. cheers.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Ilja Preuss:

Sometimes it's simpler to refactor the less OO system, though...


Is it so? Could you kindly provide more examples for that? I can't imagine how it is simpler to refactor the less OO system... I am always thinking that refactoring the perfect OO system is easier and simpler than non-(or)less- OO systems...

Thanks...


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Refactoring - consequences of changing methods to static