MVC question
-
Hi all,
I've been lurking for a while, as I have gone through most of the Cocoa
learning curve. I've come across a difficulty of sorts, that I haven't seen
addressed anywhere.
The problem that I have is with the "model-view-controller" paradigm. I
understand the idea, its implementation and significance in Cocoa and ObjC,
its history (from Smalltalk...), etc. The explanations I have found (around
the web) have, for the most part, been excellent. So have the Cocoa
tutorials...my hat's off to all the Apple documentation and Stepwise
people...
What I *do* have difficulty with is how MVC fits into the "conventional"
software engineering approach, where an application specification is given,
with succeeding steps refining the specification until code and then
executables are generated. AFAIK (at least from my limited experience) MVC
requires a different "mindset" when approaching a programming problem, but I
am yet to see/find anything that addresses this rather significant change in
the way one codes for Mac OS X. *How do I get my head around MVC?*
Am I alone in this?
Regards,
Mark
-------------------------------------------------------------------------
Mark Glossop (<mglossop...>)
"You're not me, so you're irrelevant" - Dogbert
Member of DNRC (Dogbert's New Ruling Class) -
Mark Glossop wrote :> Hi all,[...]
>
> I've been lurking for a while, as I have gone through most of the Cocoa
> learning curve. I've come across a difficulty of sorts, that I haven't seen
> addressed anywhere.> Am I alone in this?
In model-view-controller, there is the word View. So I suppose you can only
apply it to GUI stuff (I haven't think about other situations for the
moment). If you're using PowerPlant, it's quite similar to how you can code
an application using the ListenToMessage code.
--
Stephane -
Hi Mark
Strikes me that this is a thread that could run and run. From my own experience of training people to write in ObjC I'd say that a different mindset is required, and that some pople take to it very easily and that others don't (and that some wont). Whilst initially people often buck at the MVC approach, the underlying problem is often more about suddenly being faced with a truly object oriented language (as opposed to C++, ouch).
For me, the key is what you do with the specification: in conventional programming, as you say, you try to break it down until you get to something approximating the operations available to you within the programming environment. This means that from the outset you're looking for 'operations'. In object oriented programming I feel that the first thing you do when you get the specification is look for 'objects' -- this is scary for traditional programmers as they often view 'objects' as 'data', less significant than 'operations'. (The next thing you do in oo, of course, is look to see how many of your objects turn out to be remarkably, or co-ercably, similar.)
The big shift, then, is from 'being a programmer' (concerned with operations in the system) to 'being an analyst' (concerned with the dynamics of the system). In fact, whilst 'programming' is the ultimate goal of the traditional approach ('great, it's now programmable'), the aim in oo is to defer the programming as long as possible ('oh no, I've got to program something here').
So, how do you get your head round MVC... that's tough, perhaps it involves stopping being a programmer.
Hmmm...
-- Gideon -
On Fri, Jan 26, 2001 at 01:58:44AM +0800, Mark Glossop wrote:
:
: What I *do* have difficulty with is how MVC fits into the "conventional"
: software engineering approach, where an application specification is given,
: with succeeding steps refining the specification until code and then
: executables are generated. AFAIK (at least from my limited experience) MVC
: requires a different "mindset" when approaching a programming problem, but I
: am yet to see/find anything that addresses this rather significant change in
: the way one codes for Mac OS X. *How do I get my head around MVC?*
Software engineering is fundamentally still the same. I think the
problem you are encountering comes from the differences between a
procedural language versus a object-oriented language, the former
really needs a top-down approach while the latter needs it less,
and all sorts of differences in paradigms.
--
Eugene Lee
<eugene...> -
My understanding is that MVC (Model-View-Controller) design pattern has very little to do with whether you are doing traditional or object-oriented development, or what methodology you use for doing your software engineering. You can use the MVC design pattern with traditional or OO programming.
MVC is about separation of concerns within an application to promote clarity, reuse, and flexibility (and perhaps a number of other things that escape my mind at present). My understanding is that it originated with Smalltalk development (the birth place of much of OO).
The MVC pattern suggests that you separate as much as possible:
1. The Model - the business data and logic (whether it be in the form of traditional data structures and function or object) eg students, documents, bank accounts.
2. The View - the interaface components (whether this be traditional command line interface or graphical interface) eg buttons, input-output streams, windows, text boxes.
3. The Control - the application logic and data (whether it be in the form of traditional data structure and functions or objects) eg the rest of an application (ie anything else besides (1) and (2))
In simpler terms, the Model is the core of your focus (the business), the View is the interface, and the Control is the details of your application. The first two are mostly stable (ie don't change that much relativevly speaking) and the latter changes often (as often as your customer(s) demand :-)
Doing this separation properly requires that the Model knows almost (if not completely) nothing about the View(s) and the Control. And similarly for the View wrt to the Model and the Control, and the Control wrt the Model and View. It does have great benefits thought.
For example: you can have move than one view for the same model and control, you can change the view (or add additional views) for the same model and control, the model and view components (because they are independent of the application) can be reused in other applications, ...
Mostly though it helps with application development. Firstly, because you can use off-the-shelf View components, secondly because you can write and maintain your Model components independently (which means they can be clearer), and thirdly all the application details and go in the Control components.
At least that's how I see it.
Cheers,
Ashley.
PS Control components often correspond (at least at a first draft to use-cases). Jacobson has suggested allocating one control component (in OO a class) for each use-case. Later in design and development you may be able to combine a number of control components (or factor out similar functionality).
--
Dr A.M.Aitken - Senior Lecturer
School of Information Systems
Curtin Business School, Curtin University of Technology
GPO Box U1987 Perth WA 6845
Ph +61-8-9266-7075
Fx +61-8-9266-3076
Mb (04)-1226-8159
<A.Aitken...> -
Note: long winded answer.
On Thursday, January 25, 2001, at 11:58 AM, Mark Glossop wrote:
]
] What I *do* have difficulty with is how MVC fits into the "conventional"
] software engineering approach, where an application specification is given,
] with succeeding steps refining the specification until code and then
] executables are generated.
It fits in perfectly. As you might have noticed, the MVC paradigm attempts to
decouple the data from the representation. This allows the design to be easily
broken up into smaller tasks. The traditional divide and concur (SP?) methodology
of programming. A simple example might be:
A client wants you to read in a delineated text file and display this is a table.
(I know, stupid but simple.)
From a design standpoint, you might have three objects.
The Model:
This is the delineated text file. The format might be:
Date Time Event Count Error Code Error Name
You might need some simple methods to access and create the data:
-(id) initWithNameOfFile:(NSString *) fileName;
-(int) numberOfRows;
-(id) dateForRow:(int) row;
-(id) timeForRow:(int) row;
-(id) eventCountForRow:(int) row;
-(id) errorCodeForRow:(int) row;
-(id) errorNameForRow:(int) row;
Note that the storage in the actual object might combine the Date and Time into a single
NSCalendarDate. But that is a design issue.
The View:
A simple table view with 5 columns. Column IDs need assigned. This should be done to
make the controllers job easier.
The Controller:
Lots of options here. Might be a subclass of NSDocument. You might have your own simple
panel controller. There might be several views on the Window each with its own controller.
The main panel controller might be assigned to orchestrate the entire thing:
C
/ \
C M
/ \
V M
This is where all the real work is done. The key point is that the interface (View) designer can
concentrate on designing a view. The data designer concentrates on designing access to the data.
The Controller designer concentrates on how to the two talk.
The view and data designer might be a client. "I want the program to open up and present me with a
tabular view of this text file. The format is...." This might be very restricting. The problem
might be: "We need a program to track the school busses." At this point you design the Views, the
Model (For holding the data) and all of the controllers.
If you wanted, SRDs could be generated:
Upon software initialization:
The software shall [10] request the name of a "*.errormap" file to open.
The software shall [20] attempt to open for read the requested program.
On event of an error, the software shall [30] report the error to the user and then exit.
On event of success:
The software shall [40] read the requested file into memory.
The software shall [50] accept the following format in the file:
And so on. The what and when of the program. Present the requirements without regard
to implementation. This is what you functionally test to.
The SDD, would then show the organization of the MVC tree. The interfaces for the various
models, views and controllers. The How and why. This is your module level test spec.
AFAIK (at least from my limited experience) MVC
] requires a different "mindset" when approaching a programming problem, but I
] am yet to see/find anything that addresses this rather significant change in
] the way one codes for Mac OS X. *How do I get my head around MVC?*
]
] Am I alone in this?
I hope this helps.
Steven Noyes
NoiseTECH
www.noisetech.com -
Gideon wrote:> Strikes me that this is a thread that could run and run. From my ownBased on my experience of training people to use ex-NeXT technologies in
> experience of training people to write in ObjC I'd say that a different
> mindset is required, and that some pople take to it very easily and that
> others don't (and that some wont). Whilst initially people often buck at the
> MVC approach, the underlying problem is often more about suddenly being faced
> with a truly object oriented language (as opposed to C++, ouch).
>
general(*), I think that I'd go further. This "mindset" seems to be
particularly useful to enable you to successfully leverage WebObjects as
well as Cocoa, in Java as well as Obj-C. This is why I suggest that a
prerequisite for folks attending WebObjects training classes should be a
good background in Java *and* OOP -- the two are *not* the same. Many
course attendees are perfectly au fait with the Java language, but don't
seem to grok objects.
mmalc.
(*) This is a statement to give context, not intended to belittle Gideon's
experience. -
At 9:32 AM +0000 1/26/01, mmalcolm crawford wrote:> Based on my experience of training people to use ex-NeXT technologies in
> general(*), I think that I'd go further. This "mindset" seems to be
> particularly useful to enable you to successfully leverage WebObjects as
> well as Cocoa, in Java as well as Obj-C.
I'll go even further, and say that this mindset will improve
*anyone's* software engineering skills no matter what they're doing
or how they're doing it.
Even if you'll never switch from C++ or if your day job involves
writing assembly code for embedded systems, learning object-oriented
design and the Model-View-Controller architecture along with a
dynamic language like Objective-C or Smalltalk will help you by
giving you a very effective tool for modeling a large class of
problems.
You just need to figure out how to get people over the hurdles of
unique syntax, premature optimization (aka "Dynamic messaging?! That
must be slow!" Syndrome), and trying to do too much work.
-- Chris
--
Chris Hanson <cmh...>
bDistributed.com: Making Business Distributed -
> I'll go even further, and say that this mindset will improve
> *anyone's* software engineering skills no matter what they're doing
> or how they're doing it.
>
> Even if you'll never switch from C++ or if your day job involves
> writing assembly code for embedded systems, learning object-oriented
> design and the Model-View-Controller architecture along with a
> dynamic language like Objective-C or Smalltalk will help you by
> giving you a very effective tool for modeling a large class of
> problems.
The problem I experienced was the following:
* I used ObjC in tasks that could be done in C++
* I had to use C++ when I needed dynamic messages & reference counting
Sometimes it's better when you don't know what you miss when you have
to program in C++...
andy
