Hillegass - Chapter 9/Pg 149 - Breaks MVC??

Discussion in 'Mac Programming' started by LWR, Jun 19, 2009.

  1. LWR
    macrumors newbie

    Joined:
    Nov 19, 2005
    #1
    I'm coming back to development after a few years away

    Been working through Hillegass as a refresher.

    Is my recollection of good programming practice wrong, or does Hillegass break MVC?

    In Chapter 9, Page 149 there's example code added to the Raiseman application that starts auto-editing of newly added employees.

    The code wires the MyDocument (of NSDocument) to an NSTableView. Why would you ever do that? Why should the model ever 'know about' a user interface object?

    Isn't the right thing to do at that point to implement a custom employee/tableview controller that takes care of that behaviour, leaving the document class to focus on being an employee model?

    Interested in people's views - like I said, I've been away for a while so happy to learn something here.

    Regards,

    LWR
     
  2. macrumors member

    Joined:
    Jun 3, 2009
    #2
    I believe that MyDocument is the controller. But I'm new to this, so I might be wrong :rolleyes:
     
  3. LWR
    thread starter macrumors newbie

    Joined:
    Nov 19, 2005
    #3
    I guess that's my point - MyDocument has some really useful behaviour in it by Chapter 9 (create employees, undo/redo etc) it shouldn't then be forced into NSTableView as a visualisation (view). In proper MVC, the controller should be specialised for NSTableView. You should be able to reuse MyDocument (or perhaps EmployeeDocument would be a better name) with any visualisation

    Regards,

    LWR
     
  4. macrumors regular

    Joined:
    May 27, 2009
    Location:
    Glasgow, Scotland
    #4
    That part of the book is not far in Aaron will go into different techniques later on in the book.

    But yes using a Controller for the table view would probably be a better idea.

    Just my 2p worth.

    Stephen
     
  5. macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #5
    I think you're reading too much into it, I have my controls like that for D&D Manager in MyDocument. Only the real logic that doesn't do anything else is in another file.

    But for test applications I wouldn't worry too much.
     
  6. LWR
    thread starter macrumors newbie

    Joined:
    Nov 19, 2005
    #6
    OK - thanks - I'll keep the faith and keep reading on!

    OK thanks.

    I had a quick look at your D&D Manager app. Given the relative complexity of the model and the UI, if you wrote it again , wouldn't you use a dedicated controller to keep your UI options open?

    BTW, anybody else really dislike the programming style that allows two returns from a method? Hillegass seems to sue it a lot...

    if (thisWorked) {
    return YES;
    }
    else {
    return NO;
    }

    I know they're only tutorials, but I can't bring myself to copy them verbatim :D
     
  7. macrumors member

    Joined:
    Jun 3, 2009
    #7
    Haha, I guess don't have a problem with two returns :p

    But that code is begging for a refactoring:

    Code:
    return (BOOL)thisWorked;
    I'm not sure if that will work though :rolleyes:
     
  8. LWR
    thread starter macrumors newbie

    Joined:
    Nov 19, 2005
    #8

    Your refactoring works fine from a code perspective - but wouldn't have made my original point particularly well! :D
     
  9. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #9
    I think:
    Code:
    return thisWorked?YES:NO;
    Is more correct IMO, as anything non-zero in C will evaluate to true, but this isn't necessarily equal to YES. If you are returning a bool you should be able to check equivalence with YES and NO.

    -Lee
     
  10. macrumors regular

    Joined:
    Jan 16, 2008
    #10
    In ObjC BOOL is just a typedef for int. I have never seen any documented guarantee that functions declared to return BOOL will always return YES for a true value. So it would be more safe to never assume that in your code. So when testing a BOOL value for "truthiness",
    if (thisWorked)
    or
    if (!thisWorked)
    are safe, but this
    if (thisWorked == YES)
    is not.
     
  11. macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #11
    signed char, actually.
     
  12. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #12
    In all of the apple docs i read, if a function returns BOOL the return information says when NO will be returned and when YES will be returned. If you are returning a BOOL and you choose not to use these, it seems somewhat counter-intuitive. Why have a BOOL at all if you're just going to use it like a char/int/etc.?

    -Lee
     
  13. macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #13
    I think Apple would break a lot of code if it didn't.
     
  14. macrumors 68040

    iSee

    Joined:
    Oct 25, 2004
    #14
    Program defensively:

    1. Never assume a function with return type BOOL will constrain itself only to YES and NO. The easy way to do this is never compare a BOOL result directly to YES.

    2. Always ensure that the BOOL functions you write return either NO or YES, no exceptions.

    You've got redundant protection this way: both the caller and the function would have to violate the rules before your program would break.

    Also, follow rule 1. even when calling your own functions that you know return either NO or YES -- you'll protect yourself from occasional mistakes. Mistakes like this are especially easy to make when maintaining code years down the line.
     

Share This Page