james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: private vs. protected access
Date Wed, 05 Nov 2003 10:05:03 GMT
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

- - - - - - - - - - - - - - - - - -

This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may
not represent the views of Synergy Systems Limited.

If you are not the intended recipient of this e-mail and have received it in error, please
notify the sender by replying with "received in error" as the subject and then delete it from
your mailbox.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message