[ChrisNt]

Is wrong to call methods in the constructor?

import javax.swing.JFrame;

public class Test extends JFrame {
	
	private static final long serialVersionUID = 1L;

	public Test() {
		setTitle("Test");
		setSize(500,500);
		makeLayout();
		setVisible(true);
		setDefaultCloseOperation(EXIT_ON_CLOSE);
	}
	
	public void makeLayout() {		
		createJTable();
		createJButtons();
		createJTextFields();
		createJLabels();	
	}
	
	public void createJTable() {
		
	}
	
	public void createJButtons() {
		
	}
	
	public void createJTextFields() {
		
	}
	
	public void createJLabels() {
		
	}	
}

[cfoley]

Nothing wrong with that. I do it all the time.

[salazar]

A constructor is just a method that is called to allow the setting up of class. Because it is a method, you can call other methods from it as would an other method. It is probably the best thing to do when you have an especially long constructor.

This post has been edited by salazar: 11 August 2013 - 03:37 PM

[schutzzz]

salazar, on 11 August 2013 - 10:36 PM, said:

A constructor is just a method that is called to allow the setting up of class. Because it is a method

Be very careful with how you say that.

Understanding Constructors - By Robert Nielsen, JavaWorld.com

Quote

Unlike methods, constructors can take only access modifiers. Therefore, constructors cannot be abstract, final, native, static, or synchronized.

The return types are very different too. Methods can have any valid return type, or no return type, in which case the return type is given as void. Constructors have no return type, not even void.

Finally, in terms of the signature, methods and constructors have different names. Constructors have the same name as their class; by convention, methods use names other than the class name. If the Java program follows normal conventions, methods will start with a lowercase letter, constructors with an uppercase letter. Also, constructor names are usually nouns because class names are usually nouns; method names usually indicate actions.

[salazar]

You are right, thanks for catching me on that. They are referred to loosely as methods, but there are major differences. My fault.

[farrell2k]

It's perfectly fine, but it is best to make sure that only private methods that cannot be overridden in a subclass are called. Imagine this scenario what gets printed. 10 or 100? The answer is below.

public static void main(String[] args) {
	
		abstract class A {
			public int x; 
			
			public A() {
				x = 100;
				overrideThis();
			}
			
			//This method MUST println 100 for object creation to be successful.  (Imagined scenario).
			public void overrideThis() {
				System.out.println(100);
			}
		}
		
		class B extends A {
			public int x;
			
			public B(int n) {
				x = n;
			}
			
			public void overrideThis() {
				System.out.println(x);
			}
		}
		
		new B(10);
	}

0 gets printed. Why? The superclass constructor will run before the subclass constructor, and because of late binding (I think) and the type of the object being B, the call to overrideThis() in the superclass constructor actually calls the method overrideThis in class B, before B is even fully constructed. Since B inherits int x from the superclass, and because B has not yet been fully created, x = 0.

This post has been edited by farrell2k: 11 August 2013 - 11:20 PM

[ChrisNt]

That would be a tricky problem!Thanks for your example

[salazar]

farrell2k, on 11 August 2013 - 04:47 PM, said:

It's perfectly fine, but it is best to make sure that only private methods that cannot be overridden in a subclass are called.

That seems kind of strict that only private methods that cannot be overridden should be called. I'm confused. Could you elaborate please?

[farrell2k]

salazar, on 13 August 2013 - 12:53 AM, said:

farrell2k, on 11 August 2013 - 04:47 PM, said:

It's perfectly fine, but it is best to make sure that only private methods that cannot be overridden in a subclass are called.

That seems kind of strict that only private methods that cannot be overridden should be called. I'm confused. Could you elaborate please?

I already did. A great book that goes into it deeper is Effective Java. This even applies to .net languages. It's all about object creation and method call binding during object creation. In my example, the overrideThis() method is called in the superclass constructor, but instead of calling the method in the superclass type, the subclass method gets called before the subclass constructor even runs, thus everything blows up.


The timeline of events in my example is:

new A();

Superclass constructor runs and x is set to 100.
Superclass constructor calls overrideThis();

Now because we did new B(), the Java's method binding rules determine that the appropriate method to call is the one in the subclass of type B. Now, in order for B to be created, A's constructor has to finish and then B's constructor has to be called, but that doesn't happen because A's constructor calls B's overrideThis() before B's constructor is run, making x = 0.

I can explain it any other way.

Here's a super simple example. When you give people the ability to override things, they're bound to break them sooner of later. In this example a subclass of JFrame has it's setSize() overridden, and this custom version does not call up to its superclass. Assume the programmer forgot to do it. He just broke your JFrame because it does not size properly.

public class Main extends JFrame {
	private int width, height;
	
	public Main() {
		super("Test");
		setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		setSize(300,300);
		setVisible(true);
	}
	
       @Override
	public void setSize(int w, int h) {
		width = w;
		height = h;
		//super.setSize(w,h);
	}
	
	public static void main(String[] args) {
		SwingUtilities.invokeLater(new Runnable() {
			public void run() {
				new Main();
			}
		});
	}
}

This post has been edited by farrell2k: 12 August 2013 - 07:15 PM