We'll not finish this discussion, I'm afraid. And I won't struggle with the
almighty OO gurus from Sun at all :-))
BUT....
It's even better if I'm using somebody elses code bc. I can see whats going
on. No magic. Does this method take long? Will it be transacted? Are other
things influenced? NO, I'm just changing a value! Aha!
So, what I say is that making a variable public has a STRONG semantic
meaning and that is what an interface should deliver. Clear, simple
semantics.
Of course, there are enough situations where getter/setter are the way to go
and - don't think that - not all my variables are public. Most are not :)
Sometimes even technical constraints require getter/setter (e.g. RMI).
But it's a bad idea to introduce automatic getter/setter for everything just
for OO dogmatic reasons. Is my class a pure data container? Well, express
that! Don't make it more 'important' by introducing lots of methods doing
nothing. Most (99%?) of these thing will never change in future (my
experience, at least).
BTW, can the Java compiler really optimize away gette/setter overhead like a
C++-compiler can? I doubt that. But my point is not so much related to
performance anyway.
Peace,
- J
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Subject: Re: [JAVA3D] OO design vs performance
>
> That is fine as long as You are the only one using your code.
>
> It also only really works well as long as only one of you applications
> uses that class. Each additional one is just another peice of code that
> will need to be editted (and fully tested again!) when interface
> changes.
>
> If you care at all about making code reusable, then the get and set
> methods
> have a lot of value. You can't relase a library, with one API, and then
> relase it again with another without breakingthe code of the people
> who have relied on your interface.
>
> You can't change the contract! At least not without changing the class
> or package name, and leaving the old version there too. In which case
> you've doubled your work when you find a bug. Now you need to fix and
> test two classes.
>
> As far as the performance hit of setting up and tearing down the Stack
> for successive nested function calls. That's a myth these days. Any good
> compile and/or VM should be able to make enough optimizations to regain
> any performace hits incurred by writing the code with get and set
> methods.
> (which IS exactly why C++ usually doesn't take a hit on this - depending
> on your compiler.)
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
