Is it good programming practice? Constructors and instance variables

In Java, would it be a bad programming practice to do anything other than instantiate your instance variables inside your constructor?

I'm making a GUI right now, and I was thinking about coding the GUI building inside the constructor so that in my main, I can开发者_如何学运维 just make a new instance of the class to start the GUI.

That is exactly what constructors are for. The aim of a constructor is to initialise things so that the instance now exists in a program it expects to be in.

For example if you create a Window class an instance might expect to also have a Content instance and so on. However this process is not limited to things you hold a reference to using instance variables.

It's generally a good idea to package things into small/concise and understandable units.

The constructor is where intialization happens. If you're worried about writing too much code in there, you can package the UI init code into a method (call it initUI() for example) and call it at the end of your constructor

Constructor is meant to initialize your object. Now, if initializing your object need to initialize instance variables and/or call some methods or have some logic in it that's alright -- nothing wrong with that.

One of the practice that I like is not to bloat the constructor. Instead, divide the initialization code in logical chunks in separate methods and call them from inside the constructor. Like in your case,

public class MyClass{
   public MyClass(){
     this.myVar1 = new myVar();
     ...
     buildUI(param1, param2,...);
   }

   //can make it public if you think this method can call to repaint or something
   private void buildUI(Param1 param1, Param2 param2,...){ 
     ....
   }
} 

Don't forget the Builder Pattern. This pattern is designed to allow you to "build" your objects.

In Java, it is common practice to override classes such as JPanel and add the building logic internal to the constructor, in which case the class is self-building. It is also possible to create your own class that simply returns a JPanel fully constructed which is my preference. Example:

public class MyJPanelBuilder {
  public JPanel build() {
    JPanel panel = new JPanel();
    // Add all your components to the panel, lay it out how you want etc.
    // You can do it this way because all of the methods required are public!
    return panel;
  }
}

I prefer this approach as it makes it harder to violate MVC if you are simply using the widgets as supplied by the JVM.

Similarly to RAY I would advice to keep components small and focused. To make statements of Nishant and Markus more precise, the constructor is supposed to leave the object initialized, but you actually have choice how to do this.

I am usually against instatiating collaborating objects from within a constructor directly (via new operator) or indirectly (via private method call), because that makes testing harder. Sometimes you want to substitute a collaborator for a fake one to find the source of a bug. If you use new operator or a private method, you won't easily do it.

Therefore I lean to passing dependencies to my constructor via its parameters from some external place (a factory, or a builder, mentioned by Bringer128). Your constructor expects the parameters to be already initialized, so after assigning them to the object's fields, the object is ready for use.

Of course in case of dependencies, that you'll never need to substitute it's easier and still safe to instantiate them directly inside the constructor. Especially in GUIs there'll be a lot of that cases (labels and such). However should you have a dependency from outside the GUI layer (like business object), I would definately not create it in the constructor.