designing beyond MV and (one) C

  • 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, <cocoa-dev-request...> 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.
  • You might consider looking into categories.  They let you add methods
    to existing classes... for example, add an -appendDOCstring:(NSData
    *)wordDocument method to NSMutableAttributedString.  For more, see http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articl
    es/chapter_4_section_1.html

      .  It might be more convenient for you in the long run to write all
    of your parsers as categories -- if not of NSMutableAttributedString,
    maybe of NSData.

    On Jan 27, 2008, at 10:33 AM, Daniel Child wrote:

    > 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, <cocoa-dev-request...> 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.

  • >
    Cool. I think others as well have expressed similar approaches in
    their replies to your original question  and all that it needed
    was a vocabulary to generalize and its the 'strategy pattern'.

    > 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.
    >
    No harm in having a class with no member variables and its perfectly
    alright to have it in Objective C.    However there is a construct
    called as 'Protocol' in Objective C which is similar to the interfaces
    of Java.
    Read more on it:
    http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articl
    es/chapter_6_section_2.html


    Regards
    Shripada
    On 28-Jan-08, at 12:03 AM, Daniel Child wrote:

    > 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, <cocoa-dev-request...> 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.
    >
    >
    >
  • I use categories to separate out additional methods beyond the basic
    accessors and init / constructor / dealloc.

    In this case, though, since there are different subclasses, a
    separate strategies class seemed to work better. Thanks for the
    suggestion, though, as it gives me an idea for reverse sorting with
    arrays.

    On Jan 27, 2008, at 2:09 PM, Sam Stigler wrote:

    > You might consider looking into categories.  They let you add
    > methods to existing classes... for example, add an -appendDOCstring:
    > (NSData *)wordDocument method to NSMutableAttributedString.  For
    > more, see http://developer.apple.com/documentation/Cocoa/Conceptual/
    > ObjectiveC/Articles/chapter_4_section_1.html .  It might be more
    > convenient for you in the long run to write all of your parsers as
    > categories -- if not of NSMutableAttributedString, maybe of NSData.
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today