No, I believe we are exactly on the same wavelength, I would not really make the instance variables protected, just supply getters/setters, which amounts to the same functional wise, I guess I was not clear on that.
--Søren On Wednesday 05 November 2003 11:05, you wrote: >Søren Hilmer wrote: >> >> I propose the following change(s). >> >> Mainly for the supplied matchers and mailets I would like to >> reconsider having >> instance variables and methods being of private access and >> move promote them >> to protected access. > >Lets look at the intent of this change which is (please correct me if I am >wrong) to facilitate specialization by subclassing. This requires that >classes follow a few simple rules: > >1) Only expose as public methods that must be accessible to external classes >and are guaranteed to be maintained throughout the class' development >lifecycle. Such methods should ideally be defined in an interface. > >2) Only make private methods which should never be exposed to subclasses, >such as required constructors which only partially establish an instance's >state, basic getters for lazily initialized variables, etc. > >3) The remaining methods should be made protected. > >4) Public and protected methods should be sufficiently granular to enable >specialization of a sole behavior. The specializing method should not need >to duplicate code in the superclass method. (If it does, refactor!) > >5) All variables should be private and self-encapsulating, ie: access both >within and without the class should be via getter and setter methods. > >Of the above, I would have thought only (5) is particularly contentious. >Martin Fowler covers this in "Refactoring : improving the design of existing >code", p171. > >Like Martin, I am willing to live with direct access within the defining >class. > >Direct access from outside of the defining class should never be permitted >as it breaks encapsulation and increases coupling. The specializing class >should not need to know how a value is maintained and should simply invoke >the getter/setter methods. These methods may access a variable directly, >perform lazy initialization or delegate off to another class. The >specializing class should neither know or care. > >So Søren, I am basically with you on making most methods protected but very >much against making variables protected. Rather, we should make them private >and add getter/setter methods! > >-- Steve > -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
