0
votes

I'm building an app with, for the purposes of this question, three custom classes: AppDelegate, ListWindowController and ViewOptionsWindowController. AppDelegate keeps retains properties of the single instances of ListWindowController and ViewOptionsWindowController.

When the user selects a particular menu item, an action in AppDelegate is executed that instantiates the ViewOptionsWindowController. Changes made in this controller's window need to be reflected in ListWindowController's window (either adding or removing a column from the window's table view).

So, I've defined a protocol, ViewOptionsChanged, which has two required methods, -addColumn and -removeColumn (with parameters to indicate what to add or remove). I've indicated that ListViewController conforms to this protocol, and when instantiating ViewOptionsWindowController am passing AppDelegate's instance of ListViewController. The declaration of ViewOptionsWindowController's init method is:

- (id)initWithListController:(id <ViewOptionsChanged>)listController;

so that the only facts that ViewOptionsWindowController knows about the listController parameter is that it conforms to this protocol.

So, my question is, is this the proper use of Objective-C protocols? Or would some other design pattern be more appropriate?

2
Does 'ViewOptionsWindowController' need to remember when the settings change? If so, maybe having some settings object that notifies 'ListViewController' when settings have changed (whether they come from 'ViewOptionsWindowController' or not) is a more effective pattern? - tng
Currently, in addition to toggling the view of columns based on the changes made in the ViewOptionsWindowController's window, the ListViewController` is also writing the changes to the user defaults. Honestly, this doesn't seem quite right, it seems like this result of the changes should happen in the AppDelegate. - Chuck
nono, don't move stuff to the app delegate, keep it separated. It is ok that it deals with user defaults IMHO - Daij-Djan

2 Answers

2
votes

Yes .. but I think it is a tad confusing. I'd make listView a proper delegate of viewOptions

maybe name the protocol ViewOptionsDelegate and the methods viewOptions:changedTo: and put the logic to add/remove columns in the listController?

feels more cocoa like and really logic about columns don't belong with viewOptions.

but ultimately -- even if you dont agree -- it is used ok IMO.

1
votes

Delegation can be used for this, but, if this is a Mac app, consider bindings instead. Much less code, somewhat less entanglement, can be harder to debug. On either Mac or iOS, you could at least use KVO; simple to debug, somewhat less entanglement.