Reinventing the association

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Reinventing the association

Fernando Rodriguez
Hi,

I just wrote a class to represent links between html documents and
realized it's basicly an Association with different accessor names.

Do you think it's usualy worth doing this sort of thing (the meaning
is more evident if the accessors are #from and #to than key and
value)?


Reply | Threaded
Open this post in threaded view
|

Re: Reinventing the association

Chris Uppal-3
Fernando,

> I just wrote a class to represent links between html documents and
> realized it's basicly an Association with different accessor names.

If you created the class because it meant something to you, something more than
/only/ an association between the two objects, then its instances have a proper
role that is distinct from what an Association could fullfill.  Possible that
role doesn't -- today -- require any extra behaviour (no special-purpose
methods), but if you are thinking of it as something more than an Association,
then the chances are that sooner or later you will find that it needs to play a
more active part in your design.

Just as an example, if the links you are representing are HTML links, then
there are several kinds of information that you might want to know about such
links that cannot be encoded in an Association.  E.g. the location on the
source page, whether the link is via an absolute or relative URL, whether the
link is via an anchor tag <A href=...> or via an <IMG src=...> tag, and so on.

I think the point I'm trying to make is that using utility classes "raw" can
prevent you from noticing roles, relationships, or structures, that might
otherwise be obvious.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Reinventing the association

rush
In reply to this post by Fernando Rodriguez
"Fernando Rodriguez" <[hidden email]> wrote in message
news:[hidden email]...
> I just wrote a class to represent links between html documents and
> realized it's basicly an Association with different accessor names.
>
> Do you think it's usualy worth doing this sort of thing (the meaning
> is more evident if the accessors are #from and #to than key and
> value)?

It seems to me that you have 2 opposing forces, one is that you should state
one thing one and only once in the image. Second is that besides specifying
to computer what to do, Smalltalk program should communicate, talk to you
and another people reading it.

First force would tell you to use existing class, second to make your own
that talks more clearly. How about trivialy subclassing Association with you
Class, just for the communications sake, and most of the work would be done
in Association?

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/


Reply | Threaded
Open this post in threaded view
|

Re: Reinventing the association

Chris Uppal-3
rush wrote:

> How about trivialy subclassing Association with
> you Class, just for the communications sake, and most of the work would
> be done in Association?

Just an additional thought on this subject.  Associations have a specific
design to fit their role in the implementation of Dictionary; that means that
they have a non-obvious implementation of #hash, which it might not be
appropriate to inherit.

It doesn't really affect Fernando's general question, which was (I think) about
the use of utility classes /in general/ vs. creating application-specific near
equivalents, since Association isn't really a general-purpose utility class,
but it might be relevant to the example that provoked his post.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Reinventing the association

Schwab,Wilhelm K
In reply to this post by Fernando Rodriguez
Fernando,

> I just wrote a class to represent links between html documents and
> realized it's basicly an Association with different accessor names.
>
> Do you think it's usualy worth doing this sort of thing (the meaning
> is more evident if the accessors are #from and #to than key and
> value)?

Tough call.  By no means scientific, I note that my CodeGenerator IDE
extension (I'm thinking of the constructor feature) has some miles on it
now, and I do not have any regrets about the classes it produces.  Some
start out as contexts that could be represented with associations or
arrays.  However, as Chris and Rush point out, having a dedicated class
allows me to later introduce behavior as I learn what I should have done
from the beginning :)

Another point in favor of dedicated classes is that the selectors end up
being less generic, so browsing/refactoring/etc. becomes easier.

Of course, I am not suggesting that you should never use system classes
as delivered.  When it makes sense, have at it.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]