Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Laurence Tratt (laurie@tratt.net)
Date: Tue 18 May 2004 - 15:59:15 BST


On Mon, May 17, 2004 at 02:32:32PM -0600, robert france wrote:

Dear Robert,

> Hmmm, I thought that optional attributes were considered bad OO practice
> (from an object cohesion perspective). Can someone give a good example of
> where an optional attribute is a good design choice (i.e, justify the need
> to provide support for such attributes in the UML)?
>
> Here's my take: An attribute (from the pUML submission) is a "slot". If an
> attribute has a multiplicity 0..1 I would interpret this as "there is no
> slot or there is exactly one slot for the attribute". If there is no slot
> then we cannot store values for the attribute. If there is a slot we can
> store a value in it. For requirements and design modeling I assume that the
> slots always contain values (i.e., I consider a class diagram to be a
> characterization of valid stable "states" where a state is an object
> configuration); and thus I cheat (i.e., ignore the slot concept) and treat
> (mandatory) attributes as logical variables. Is this view is no longer
> supported by the UML semantics?

I think there are (at least) two possible interpretations of "optional
attribute". The one you've outlined is one, albeit a slightly extreme
interpretation :) In practical situations, I think optional attributes mean
that an attribute can take a NULL value. This is *definitely* not bad OO
design: it's impossible to do without it when one is programming anything of
any size. Some OO languages are very brain dead (I'm thinking of C, C++ and
Java as the most well known candidates) and have some types of attributes
that can't have NULL assigned to them - that's their loss, but it doesn't
negate its use in more sophisticated languages.

The position you've outlined is interesting, although note that if an object
doesn't possess a slot X' for an attribute X, then the type system of the
language has been subverted at run time (unless one defines that attempting
to access a slot which doesn't exist returns OclUndefined or equivalent). So
one probably wouldn't choose to do that in practise.

Most languages that I am aware of do not, at the user level, differentiate
between "this value has NULL assigned to it" and "this value is undefined" -
NULL is all that is given to the user. Note that I am aware of several
languages which *internally* have a way of noticing that certain variables
and slots have not yet been assigned to, but there's no way for the user to
test for this other than causing an exception to be generated. Certainly, my
own Converge language follows in these footsteps, so that I can detect
people attempting to read from variables before they have been assigned an
initial value. Once an initial value has been assigned (be it NULL or
anything else), it is impossible for the variable to return to the
"undefined" state.

Yours,


Laurie
-- 
http://tratt.net/laurie/

Date view Thread view Subject view Author view Attachment view