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)? |
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 |
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/ |
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 |
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] |
Free forum by Nabble | Edit this page |