Re: Acid Test For MVC Design?
Re: Acid Test For MVC Design?
- Subject: Re: Acid Test For MVC Design?
- From: Nathan Day <email@hidden>
- Date: Wed, 31 Jul 2002 18:33:32 +0930
AN approach I use sometime is too develop my program in part, for
instance I'll start a project as a command line project, and use just a
c function like fgets to get command strings, I have a class that can
handle this for me by using it's own NSNotificationCenter. I can then
build the model classes and test them and then think about how to put an
interface on it after. Or with a project I'm working on now I have some
complicated view objects so I've stated a new project to develop and get
them working. The controller objects are then what is use to join those
two worlds together.
On Wednesday, July 31, 2002, at 05:28 AM, Daniel Jalkut wrote:
The hardest part about Cocoa/ObjectiveC programming for me so far is
the unsteady footing I have on the "MVC design" paradigm. I think I
have a good notion of the approach, but sometimes I get stuck trying to
classify a certain class into one of the categories. At times, I wish
I had some kind of "key questions" to ask about the functionality to
help determine what it is. Sometimes, I think I get stuck because the
class I'm looking at inadvertently covers both model and controller, or
both view and model, or perhaps all three.
Does anybody have some kind of "MVC boot camp" - a bunch of examples of
pure MVC design that perhaps quiz the reader to determine the
philosophically correct home for each component. Or just a newsgroup
or source of writing where I could read a lot about the
"classification" thinking that must go along with this design approach?
Some particulars that confuse me a little, and my attempts at
understanding them:
NSSound - the sound data itself is obviously model. Is the "playback"
best classified as "View" even though it's not seen? I assume that
anything that interacts physically with the user is "view". Does this
mean a microphone input for speech recognition would technically be
"View" as well? Assuming all this is correct, does "NSSound" actually
provide a view and model in one (NSSoundData and NSSoundPlayer) that
are just coupled together for programming convenience? And is the
reason they're coupled together because each of them is relatively
useless as separate objects on their own?
NSString - similarly, does the NSStringDrawing category take NSString
from the realm of model to the realm of view? Or is the
NSStringDrawing category more like "Controller" in that it connects up
the model with the actual view (the screen).
I feel like if I get my head thoroughly wrapped around this stuff
before I embark on a large project, I will save myself a lot of
rewriting/designing.
Nathan Day
http://homepage.mac.com/nathan_day/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.