Re: [digression] Why is it like this?
Re: [digression] Why is it like this?
- Subject: Re: [digression] Why is it like this?
- From: Andy Lee <email@hidden>
- Date: Tue, 31 May 2005 16:24:07 -0400
On May 31, 2005, at 8:44 AM, Raffael Cavallaro wrote:
On May 30, 2005, at Mon, May 30, 10:57 10 PM, Andy Lee wrote:
It would be convenient for the objects to have methods like -
stringToDisplayInXYZBrowser and -
stringToDisplayInABCContextualMenu, but this means model objects
would be aware of the specific views they will be displayed in.
One solution would be to have more abstract methods in the Model
class - for example -shortString -longString. Then each view's
Controller class would call -short/longString as needed.
Yes, it would be nice to keep things abstract, but eventually
specific needs catch up with me. For example, if I package my model
classes and drop them into a different application, I may find I have
different needs in that application than -shortString and -longString
were intended for. They may punctuate strings slightly differently
than I want. Or I may have completely different needs, like -
internationalizedShortString, or -syntaxHighlightedAttributedString,
or -htmlString, or -xmlString, or -sqlString.
Since these are behaviors that would vary for different classes in my
model hierarchy, I'm thinking that categories might make sense, and
in fact might be an elegant way to solve the problem that couldn't be
done in most languages besides Objective-C. For example, I could add
the -htmlString method to various model classes, and then I'd simply
be able to ask a model object for its -htmlString; the semantics is
very clean, and I wouldn't be polluting the original model
framework. I could still bring the model framework to another
application and have that application also add -htmlString, with a
different implementation.
I don't remember why I'm not using categories, but it makes sense to
me now, on paper. I'm usually wary of making a class "bigger" than
it has to be; but this kind of extending by categories is probably
fine in that it partitions class functionality so it's not to ugly to
manage.
So you might keep your hypothetical -stringToDisplay… methods in a
hybrid Model-Controller class.
Yes, this is sort of what my lightweight wrapper objects are. I have
a parallel hierarchy of these objects, each knowing how to display a
given type of model object in all the ways my application needs.
Parallel class hierarchies always make me wonder whether I didn't
design things right. (Well, I *know* I didn't, because I'm
constantly refactoring this thing; but parallel hierarchies add to my
concern.)
On May 31, 2005, at 9:51 AM, Sherm Pendley wrote:
Not really sure what your overall design is,
To be a little more concrete: imagine the traditional example of a
hierarchy of shape classes:
Shape
Curve
Oval
Circle
Bezier
Polygon
Segment
Triangle
Quadrangle
Trapezoid
Rectangle
Now imagine your UI has:
* an NSBrowser for navigating this class hierarchy;
* an NSTableView that displays various lists of shapes (like all
the closed shapes, or all the symmetrical ones, or all the ones with
"r" in them); and
* a menu that lists the user's favorite shapes.
So a given shape could be represented as a string in three different
places in the UI. There are two variables in how the display strings
are derived:
(1) which shape class is it (because the string for a Rectangle is
different from the string for a Bezier)? and
(2) which UI element is it (because maybe the display string for a
Circle is slightly different in the menu than in the table view)?
The way to handle (1) is using polymorphism somewhere -- either via a
parallel class hierarchy (ShapeStringGenerator, OvalStringGenerator,
etc.) or using categories on the shape classes. The way to handle
(2) is by having multiple string-generating methods, as in -
stringToDisplayInBrowser or -stringToDisplayInFavoritesMenu.
but isn't that pretty much the situation that the NSFormatter and/
or NSValueTransformer classes were made for? They both act as
intermediaries whenever there's an "impedance mismatch" between
what the view needs, and what the model provides.
Ah, I hadn't thought of that. I think what I've essentially written
is my own NSFormatter-like classes, without the need for editability
and with more than one kind of -stringForObjectValue:. I guess you
could say I used the same design pattern as NSFormatter. I'm just
wondering now whether I should move the behaviors into the model
classes via categories.
--Andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden