Re: contructors setters or both

From: glunk (stowe_at_whackthisvsac.org)
Date: 06/30/04


Date: Wed, 30 Jun 2004 10:02:14 -0400


"Chris Smith" <cdsmith@twu.net> wrote in message
news:MPG.1b4c72da36907cce98969f@news.altopia.net...
> glunk wrote:
> > I went to a Java class (training!) a while ago. The instructor was
actually
> > a real programmer. I am used to Microsoft training in which the person
doing
> > the training does not actually ever DO the work. Anyway, the instructor
told
> > us it was a good idea to either set the values of instance variables by
> > passing them into the constructor OR by setter methods, but not both.
>
> I'm not sure exactly what your instructor was referring to here. What
> he/she *may* have been talking about is that there are occasions where
> you ought to consider writing an immutable class, in which there is no
> way to change the data stored in an object after it has been created.
> Examples from the core API include java.lang.String and
> java.lang.Integer.
>
> Immutable classes have a number of advantages, including that they can
> be safely shared between threads and between pieces of the program,
> without worrying that one piece of code will change the data in the
> object and interfere with other code that is also using the same object.
>
> However, once you've decided to make an object mutable (i.e., it can be
> changed), there's no reason not to also provide a constructor that lets
> you set an initial value. There's also no requirement that if you write
> such mutator methods, that you use them from inside the class (although
> you certainly can; see below). Mutators are quite convenient for
> external use as well. For example, it's easier to say:
>
> return new Appointment("Dr. Johnson", apptTime);
>
> versus:
>
> Appointment appt = new Appointment();
> appt.setDoctor("Dr. Johnson");
> appt.setTime(apptTime);
> return appt;
>
> > We were going to do this kind of thing
> >
> >
> > public MyClass (String lastName, String firstName)
> > {
> > setLastName(lastName);
> > setFirstName(firstName);
> > }
> >
> > to ensure that any setter code which may do something to the value is
used.
> >
> > But then, if you can see my other post entitled "getting used to Java -
> > question about 'style'" this seems to be calling a nonfinal method (the
> > setters) from within a constructor.
>
> Yes, it is, assuming that the class is not final and that the mutator
> methods are not final. Are you designing this class for use of
> inheritance? If so, then you would indeed need to work this out.
>
> For the most part, mutators aren't used from inside the class where you
> use them, which would solve this problem for you. The most important
> unit of encapsulation in an OO language is the class, and it's okay to
> break encapsulation inside of a class, because you assume that you're in
> control of all that code.
>
> Of course, use of mutators even for private fields (sometimes called
> self-encapsulation) can be a nice implementation convenience to avoid
> duplicating code. In this case, one possibility might be to provide
> both private mutators (for self-encapsulation within the class) and
> public mutators (which just call the private mutators by default), and
> then call the private mutators directly from the constructor. That
> means you end up with *two* mutators for each field, though, which can
> get unwieldly rather fast.
>
> > Can someone comment on whether or not it is generally wise to not have
> > setters if the instance vars have to be set in the constructor? In this
> > example, I cannot even think of a value changing.
>
> Sounds like, in this case, you'd be better off going for an immutable
> class, and not providing any mutators at all. It really depends on your
> overall design, though, so I can't make that call for you.
>

Thanks. You are very good at explaining.

S



Relevant Pages

  • Re: Why is recursion hard?
    ... And I'm meeting lots of people who, for whatever reason, can't wrap their brains around recursion, or who, at least, consider it to be an "obscure" way to do things, and I just don't understand what the barrier is. ... My scheme code is almost completely functional; I don't even think about making it that way, I just wind up not using mutators because I don't need them. ... So there's a mutator in the copy constructor, ... But that's performance tweaking, ...
    (comp.lang.scheme)
  • Re: contructors setters or both
    ... The instructor was actually ... > passing them into the constructor OR by setter methods, ... mutators aren't used from inside the class where you ... public mutators (which just call the private mutators by default), ...
    (comp.lang.java.programmer)
  • Re: Constructor with a lot of arguments?
    ... A constructor with a lot of arguments has the same ... the variables that are now set through mutators. ... special class whose job is to hold data for the one- ... for a moment about how StringBuffer ...
    (comp.lang.java.help)
  • Re: contructors setters or both
    ... >> setters if the instance vars have to be set in the constructor? ... and not providing any mutators at all. ... For me, though, sooner or later, my classes end up needing to be ... needing the default constructor and get/set methods. ...
    (comp.lang.java.programmer)