On 11/22/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 11/23/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 11/22/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > > > Is there any objection to me changing instance variables from > "protected" > > > to > > > "private"? > > > > > > +1 unless there are already subclasses that access such variables from > their > > superclass ... in which case we should evaluate whether a getter method > > might be better. You can always loosen access rights later, but you > can't > > put the toothpaste back in the tube. > > There are only two where this is the case.DatabaseBasicMessages > sets/gets the key and values variables inherited from BasicMessage. > BasicMessage has getters but no setters, but DatabaseBasicMessages > implements setters. Could either leave it as is, or move the setters > out of DatabaseBasicMessages and into BasicMessage. For now I'm going > to leave it as it is, unless someone shouts.
To use Craig's metaphor, this is really another toothpaste in the tube thing - if we don't create getters / setters now, we won't be able to do that later if we need to, for example if the variable gets moved to a different class or the value is derived in some other way. -- Martin Cooper The other one is the static "factory" variable in Messages - at the > moment the only reference is in one of the test classes which sets it, > but making it private would mean it can never be changed from > ResourcesBundleResourcesFactory without a static setter being added. > Again I'm going to leave it as it is, unless someone shouts. > > > Niall > > > > > > Craig > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
