• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OOP problem

 
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
A berm makes a great wind break. And we all like to break wind once in a while. Like this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic