   OOP: Problem overriding a method used in a superconstructor!  How to workaround?
  I have a constructor for a superclass, GravitationalBody, that calls a method:image = loadImage()loadImage() returns a BufferedImage from a SpriteStore.There is a subclass of GravitationalBody, RoundBody, in which the method loadImage() has been overridden by me to instead CREATE a BufferedImage made up of randomly chosen colors and lines.  However, in this overridden method, the return is initialized as thus:loadImage(){image = new BufferedImage(radius*2, radius*2, BufferedImage.TYPE_INT_ARGB);etc....}However, radius is a field that only belongs to RoundBody, not GravitationalBody, and thus is not initialized yet.  A runtime error generates when creating a roundbody, because BufferedImages cannot be started with widths/heights of 0, and GravitationalBody uses the overridden loadImage() when initializing Roundbodies.  I've been using a workaround where I have a second method, titled planetGenerate(), which does the exact same thing, but is called in the RoundBody constructor.  It works, but it irks me to no end that everytime the RoundBody is initialized, the loadImage() is called uselessly because it is overridden by planetGenerate().Any OOP suggestions?   
  In C++ land we're not allowed to use virtual functions in constructors at all (well you can, but they don't work as usual). I'm (unfortunately?) indoctrinated in the C++ OOP ways, so I'd look at your design and see the use of virtual within a constructor as something abhorrent and to be redesigned ;)As you mention, when the base constructor runs, the derived type hasn't yet been constructed, so trying to use polymorphic behaviours at this point isn't going to work.Instead of using a polymorphic function in a constructor (to let the derived type choose how to construct itself), you should just be able to do that work from within the derived type's constructor (which is going to execute soon enough anyway).   ;  Perhaps instead of making the constructors for these classes publicly accessible, you should have a static factory function on each class which constructs the object and then calls the loadImage method on it.   ;Quote:Original post by CyJackXAny OOP suggestions?IOC. Inversion of Control.class GravitationalBody {  public GravitationalBody(Image img, ....) {    this.img = img;  }  private Image img;};...Image img = loadImage(.....);GravitationalBody b = new RoundBody(img, ...);Simple guideline is - never use new in constructor. Never do any logic in constructor, just assignment of variables passed in.Pass all dependencies during construction.Quote:where I have a second method, titled planetGenerate()This makes it something like an image factory. Usually, configuration will come from outside, perhaps via XML or text file, or similar. Let's have a Map<String,String> into which parameters have been parsed.class ImageFactory {  static Image createImage(Map<String,String> config) {    if ("random".equals(config.get("type")) {  double r = Double.parseDouble(config.get("radius"));  Image img = // make random image with radius r  return img;    }    if ("planet".equals(config.get("type)) { // make image of planet return img;    }    // oops    return DefaultImage; // placeholder, usually image of [ERROR] written in red or similar  }}Then it becomes simple:Map<String, String> m;m.parseConfig("my_settings.foo");Image img = ImageFactory.createImage(m);GravitationalBody b = new SomeTypeOfBody(img, ...);This moves all configuration out of code and into external files.Quote:In C++ land we're not allowed to use virtual functions in constructorsHorrors like BufferedImage exist in Java only.   