designing beyond MV and (one) C
designing beyond MV and (one) C
- Subject: designing beyond MV and (one) C
- From: Daniel Child <email@hidden>
- Date: Sun, 27 Jan 2008 13:33:29 -0500
Great suggestion, thanks!
Sorry for the long delay in responding. I liked your idea but got
sidetracked learning how to manage controllers and communicate
between them, as well as how to use delegation.
I've opted to go with....
- A central controller to collect data needed by all parsers.
- Separate window controllers to manage the GUI for other data
specific to the file to be parsed.
- A Parser class for data to all parsers (basically abstract since I
never call it) with subclasses for other parsers (flat file,
nonuniform, XML, etc.) that store relevant data particular to that
kind of parser.
- Record parsing strategies (a class with no instance variables) for
uniform structures, nonuniform structures. (May need doc parsing
strategies for more complicated parsing situations, but I haven't
gotten that far yet.)
-Generic record and generic table classes.
So I roughly followed your suggestion by setting up a separate
strategy class.
I'm wondering, though, whether I haven't done something strange by
setting up a RecordParsingStrategies class with no instance
variables? Or is that how you would do it in Objective-C. There's
nothing that seems to correspond exactly to the "implements" keyword
in Java, so I just made a field-less class with methods. (I guess
they could just as well have been plain functions.) If there is a
better way, please let me know. Otherwise, thanks for the tip.
On Jan 14, 2008, at 10:20 AM, email@hidden wrote:
In the MVC paradigm, do you typically use a different controller for
each major interface? Should I have three controllers, one to handle
each type of parser? Three window controllers, to handle each major
settings interface?
Look into the 'strategy' design pattern. All that you can do is have a
single controller with appropriate
strategy for each of the file type use different strategies
dynamically for parsing them.
http://en.wikipedia.org/wiki/Strategy_pattern
I would propose a solution something like this:
A ParserController class. This will dynamically associate with a
subclass of an abstract 'ParsingStrategy'
class. Lets imagine that we are parsing an RTF, a DOC and a PDF file.
What I would have is classes: RTFParsingStrategy,
DOCParsingStrategy and PDFParsingStrategy - all are subclasses of
ParsingStrategy. And each of these parsing strategies
will associate with appropriate window controllers of their own to
facilitate the necessary UI. I recommond having one window controller
per window. ParserController can also act as the window controller
for your 'Entry UI'. The same can have intelligence to decide which
strategy at runtime. This design makes it extremely flexible to add
new strategies as you introduce new file types.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden