On 11/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > 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.
OK I'll make the changes - I was just trying to be lazy :-) Niall > -- > 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]
