re: dual controllers
re: dual controllers
- Subject: re: dual controllers
- From: Keith Ray <email@hidden>
- Date: Sun, 13 Oct 2002 11:33:56 -0700
[...]
I am trying to decouple as much of my program as possible and
separating model and view logic into different controllers seems like
a good idea, but I have not been able to figure out how to do it, or
find any discussion on the topic. Perhaps it is so simple that no one
has bothered to explain it. For a smart guy I can be awfully dense at
times.
Brian E. Howard
This actually is a difficult subject, and one that isn't well-described
in how it relates to commonly used frameworks like Cocoa, PowerPlant,
and MFC. I haven't yet seen many good discussions in books, though
there are several books on my to-read pile that might have them.
One or more Smalltalk environments (VisualWorks), have the concept of
"ValueModel" objects, which can decouple a model from a view at very
low levels (for example, a one button "view" can be linked by an
ValueModel Adapter to a single boolean variable in your model.) There
seem to be docs at
<
http://www.exept.de/exept_99/onlineDoc/english/programming/
vmodels.html>.
Because of Objective-C's relationship to Smalltalk, it theoretically
would be very easy to port this ValueModel concept to Cocoa (it might
require extending via subclasses or class categories all of the current
widget objects to add some of the necessary features). With
considerable difficulty, this concept has been ported to Java and
called "XMLTalk"
<
http://www.trcinc.com/knowledge/software/xmltalk/xmltalk.asp>.
It is also an interesting "lack" that the book "Design Patterns" by
Gamma, et al., doesn't have the ModelViewController pattern as one of
its patterns... perhaps because of their rule that a pattern had to be
found in three independently-developed pieces of software to qualify
for inclusion in the book. The original Smalltalk "controller" is now
built into our operating systems -- the thing that listens for events
and routes them to the correct widgets -- so ValueModel may be more
helpful as a design pattern.
Another way to get your domain/model classes separate from the GUI
classes is to write them test-first (aka TestDrivenDevelopment/TDD,
TestDrivenDesign). A book on this subject is at
<
http://www.amazon.com/exec/obidos/ASIN/0321146530/qid=1034532395/
sr=11-1/ref=sr_11_1/103-3841993-4871027>. There are two
objective-C frameworks for doing TDD mentioned here
<
http://www.xprogramming.com/software.htm>.
--
C. Keith Ray
<
http://homepage.mac.com/keithray/xpminifaq.html>
<
http://homepage.mac.com/keithray/resume.html>
_______________________________________________
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.