Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [digression] Why is it like this?

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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Why is it like this? (From: Gregory Weston <email@hidden>)
 >Re: Why is it like this? (From: Thomas Davie <email@hidden>)
 >Re: Why is it like this? (From: Gregory Weston <email@hidden>)
 >Re: Why is it like this? (From: Thomas Davie <email@hidden>)
 >Re: Why is it like this? (From: Aaron Fothergill <email@hidden>)
 >Re: Why is it like this? (From: Andy Lee <email@hidden>)
 >Re: Why is it like this? (From: Raffael Cavallaro <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.