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

[LWR]

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

 

[isharan]

I believe that MyDocument is the controller. But I'm new to this, so I might be wrong

 

[LWR]

I believe that MyDocument is the controller. But I'm new to this, so I might be wrong

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

 

[SRossi]

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

 

[Eraserhead]

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

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.

 

[LWR]

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

OK - thanks - I'll keep the faith and keep reading on!

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.

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

 

[isharan]

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

Haha, I guess don't have a problem with two returns

But that code is begging for a refactoring:

return (BOOL)thisWorked;

I'm not sure if that will work though

 

[LWR]

Haha, I guess don't have a problem with two returns

But that code is begging for a refactoring:

return (BOOL)thisWorked;

I'm not sure if that will work though

Your refactoring works fine from a code perspective - but wouldn't have made my original point particularly well!

 

[lee1210]

I think:

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

 

[bilboa]

I think:

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

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.

 

[Catfish_Man]

In ObjC BOOL is just a typedef for int..

signed char, actually.

 

[lee1210]

II 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.

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

 

[Eraserhead]

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.

I think Apple would break a lot of code if it didn't.

 

[iSee]

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.