• Post Reply Bookmark Topic Watch Topic
  • New Topic

OOP problem  RSS feed

 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I have this OOP problem that I've come across before as I'm sure others have.
I basically have:


So basically, the problem is in the DEF constructor, if I initialize x after calling super(), which I'm kind of forced to do, then when doSomething in DEF is called, it will use the value x = 0. Does this mean my code is poorly designed as it doesn't fit in with OOP principles, or is it just an effect of OOP itself, in which case, what ways are there of getting round it?

Thanks for any help.
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I recommend to use constructors only for object initialization and not to perform actions (unless the scope of the function is private because then it won't cause problems). I don't know any way to get around it.
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please forgive a greenhorn question, but what OOP principle is being violated?

Jim...
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never apologize to ask a question. Questions are to way to knowledge . It's not really a principle but more a OOP problem. If you call a function then, if available, the overridden version is used. Normally that is fine. However if you do so in a constructor then the subclasses instance variables declared in the subclass still have the default values because the super constructor has not finished yet. I wrote a simple example here.
 
Ireneusz Kordal
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim Hoglund wrote:Please forgive a greenhorn question, but what OOP principle is being violated?

Jim...

None.
But you will get unpredictable side effects and strange errors that will be difficult to track/resolve.
Try to run this example:

Result is:

This is because of a way java initialises objects - super class is initialized first before it's subclasses.
In the superclass constructor you call overridden method defined in the subclass,
this method refers to members of the subclass that are not initialized yet ... and this cause errors.
In the above example x=0 and y=null even than x is declared as 10 and y should be initialized to 20.
Remember that some time in the future your class could be used/extended by someone other
who will get strange errors that will confuse him.
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Initialization order is well defined: parameters (top-to-bottom), init blocks (top-to-bottom)
and then constructor code, first in the highest super class and then on down the tree. How
would strange errors and unpredictable side-effects appear in the future? It seems pretty
clear that one should not call a method down the tree from a super-class constructor. And
if it isn't flagged at run-time, a basic code review should catch it. Maybe another lesson is
that init() methods should be private and/or final (along with all params).

Jim...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!