In main method which should I use?

CarOwner owner = new CarOwner("Danni", "123456789");


CarOwner owner = new CarOwner();

I know how to make both work, I can edit the class file to suit whichever way it is written in the main method. But what do people do in real life?

Can someone confirm if these are fact or myth?

  • to set an inital value of a class property you use a constructor
  • you use setter methods instead of using constructors
  • you use the setter methods to 'modify' a property
  • using a constructor or setter method to set a property depends on whether the property value is likely to change

Recommended Answers

All 9 Replies

Yes..what you said is true and depends on the person and requirement to decide which one he/she should use. Absolutely it doesn't make difference whether you use constructor or setter methods.
If you have a constructor that accepts arguements, then you can happily initialize in the constructor itself. Otherwise you can use setter methods instead. Either way , both approaches results same.

You can say

 JFrame f=new JFrame("this is title");


 JFRame f=new JFrame();
 f.setTitle("this is title");

Both are SAME.. BUT observe one important thing in the above code

In the first method , we are directly calling the constructor which accepts the title value.
Where as in the second method , we are setting the title value using Setter method.

In the first case, if you want to change the title of the jframe sometime later in your code ,you CANT change it . You have to create a new object inorder to change the title which is not what you need.

Where as in the second code , you can change the title of the jframe at any given point of time by just calling the setter method.

So it all depends on your requirements.

both are good , and usually it depends on the particular code your working in. but if the 1st method can be done , ie if the values to set are known at the time the new instance is created , i cant see why not to use it... makes the code shorter and more compact.
However , when the values to set are not known atthe time you call the new on any object , then you have your default no arg constructor , and set the values at a later time using the setter methods.

in most cases, both are used.

to give a little rl example ... you buy a car, after a while you get bored of the color and have it painted, so:

Car myCar = new Car("BMW", 4, Color.Blue); // type, nr of doors, color -> initial values, the way you bought it

and, later on:

myCar.setColor(Color.White); // just because you change the initial value of the color, doesn't mean you need to buy a new car, right?

In the first case, if you want to change the title of the jframe sometime later in your code ,you CANT change it . You have to create a new object inorder to change the title which is not what you need.

@harinath: Do you have any reference material or sample code to support this assertion?

You may want to run this:

import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JFrame;

public class TitleChanger {

   static JFrame frame = new JFrame("Harinath says this can't be changed");
   static int counter = 0;

   public static void main(String[] args) {
      frame.setMinimumSize(new Dimension(500, 200));

      new javax.swing.Timer(3000, new ActionListener() {
         public void actionPerformed(ActionEvent e) {
            frame.setTitle("changed " + ++counter);



Which you use depends heavily on the intended data security. If you want class instances to be resistant to outside change after creation, you will not create setter methods, setting fields exclusively through the constructors and/or internal calculation.

If you want/need your class' fields to be editable after instantiation, you need setter methods.
Having a constructor that takes initial values as an argument may or may not be prudent in such cases, depending on whether it is likely all fields will ever be available on instance creation.

Both are at times valid requirements, neither is universally bad or good.

One case where I would use the constructor is where you have a mandatory immutable value. This will often happen when the value is used as a persistent ID in an underlying database. In that case I would declare the variable final and set it in every constructor.

@harinath: Do you have any reference material or sample code to support this assertion?


I think you haven't read my entire post. What i mean is If you are creating a jframe object with constructor passing the title value and if you want to change the title of the jframe later , YOU MUST USE SETTER METHOD otherwise you need to create a new object which is not what we want just to rename the title.

So you ended up using setTitle() method at line 19 in your code. Thats what I said.
Can you change the title of the jframe without that line 19.? (without using setter method).
You Cant. So Setter method allows us to modify the value later. That's what I said and i think you haven't read my post fully or you might have misinterpreted my post.

JFrame f=new JFrame("Mr. JamesCherrill, this title cant be changed unless you use setter method or create a new object");

LOL..afterall i am working with swings from past 4 years. How can you expect that i think such foolishly?.
Anyway..please read the post completly and understand it clearly before posting anything. That is what I do everytime.
I hope you will also do that.

No, I did read carefully, because I was so surpised by what you wrote. If you had defined and used some artificial class example then the point would have been clear. But by chosing JFrame you chose a well-known class that has well-known methods, and what you wrote was incorrect for that class.
I commented because a novice could read what you wrote and believe that you can't change the title of a JFrame if you have set it in the constructor. It was just an unfortunate choice of example, that's all.

Thanks for all your replies.
The use of constructors and setter methods are becomming clearer to me now.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.