avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Proposal] WriteProtectable/ReadOnly interfaces
Date Tue, 10 Jun 2003 12:32:30 GMT
Anton Tagunov wrote:
> This mail is on introduction of WriteProtectable/ReadOnly.
> Do you think it's a good idea to put them somewhere to the framework
 
No.

The concept of something being read-only should be specified in the
interface the client uses to interact with the object. Preferably by
not providing any methods the client can use to change the object.

I.e. If I give you a XBean class, then
the XBean contract is ***all*** you have to care about. You shouldn't 
have to worry about whether the XBean instance you got may also
implement
ReadOnly or whatever.

For example, consider this:

    class Bean {
        int i;
        public void set (int i) { ... };
        public int get () { ... };
    }

    class ReadOnlyBean extends Bean implements ReadOnly {
        public void set (int i) { throw new
UnsupportedOperationException(); };
    }

Why is this bad architecture? Because if you have a method:

    public void useBean (Bean b) {
        // Is it safe to call Bean.set here?
        if (b instanceof ReadOnly) // grumble, grumble why do I have to
test this
                                   // EVERY TIME???
    }

Better way:

    class ReadOnlyBean {
        protected int i;
        public int get () { ... };
    }

    class Bean extends ReadOnlyBean {
        public void set (int i) { ... };
    }

Then you know that you can call any method provided to you without
having to worry about some of them maybe not being there. == Stronger
contracts == fewer bugs.

The ReadOnly interface messes up the contracts for absolutely no 
benefit.

Regarding the WriteProtectable interface:

Making something read-only is almost always done as a part of the 
creation process: You create an object, then you initaialize it
somehow, then you make it read only and finally you pass it to
clients.

The thing is that if you are the one creating an object, you already
know everything about it, and you should call the object's own
makeReadOnly() method.

If you don't know everything about the object you are initializing,
for example, if you use an abstract factory to create the instance,
how can you be sure that you are allowed to make it read-only?

/LS


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


Mime
View raw message