• Post Reply Bookmark Topic Watch Topic
  • New Topic

Constructors vs. mutator methods  RSS feed

 
James Chegwidden
Author
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A question was posed to me by one of my students about this code:




The overloaded constructor and the set methods are basically the same. The question was why have them both in the code. I said it depended on the application. Constructors initially set the values of instance variables set methods are used to change variables while application is running. Also, I said maybe the set method my need additonal logic for that instance variable.

This explanation did not seem clear to them. could anyone provide another reson why the I would have the situation above happen. to tell my students

JC
 
M Anderson
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recall that the purpose of a constructor is to be able to instantiate the object with a 'known' state (this is the main reason why you'd never want to throw an exception from a constructor). Mutator methods give the user the ability to change the object's state later.

Giving the user the ability to create the object, using a constructor that takes parameters is really a convienience and offers the user some, albeit implicit, control over what state the object has when it's created for the first time.

Also, having setter methods (and getters) for each property makes the class a 'JavaBean' which could have advantages, depending on what you're using the object for in your program.
 
Vijay Raj
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When class Person is extended as a FireFighter, there would be no other way to change the name of the firefighter without a mutator method (if firstName and lastName are made private which the should be).

regards,
vijay.
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's another variation...

The job of a constructor is to return an object that's ready for use. In this case, as soon as you have an instance of Person, that instance is immediately ready for use (in particular, you can call getFirstName on it).

One situation in which this is useful would be in creating an anonymous instance within a method call...

community.add(new Person("John", "Doe"));

Without that constructor, the above line would need to be something like...

Person jd = new Person();
jd.setFirstName("John");
jd.setLastName("Doe");
community.add(jd);

Of course, a person's name might change later, so the mutator methods are also available.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a lot of goodness in immutable objects, or maybe a lot of opportunity for badness around mutable objects. The Java Bean convention of a full complement of getters and setters is not a good model to follow for object design. I'd follow the constructor model as long as the number of parameters is reasonable. A real business need to change names would sway me to do something different, but I'm not sure what yet.
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by M Anderson:
...(this is the main reason why you'd never want to throw an exception from a constructor)...


Why not? There are plenty of constructors in the API that throw exceptions(Socket for one). If your constructor can cause an exception, why not throw one? In the case of Socket, a Socket instance that is not connected to something is not very worthwhile.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!