Re: Sorry for another NEWBIE question
Re: Sorry for another NEWBIE question
- Subject: Re: Sorry for another NEWBIE question
- From: Public Look <email@hidden>
- Date: Wed, 19 Nov 2003 13:40:48 -0500
On Nov 19, 2003, at 12:28 PM, Michael Becker wrote:
Hi!
Sorry to bother you all with silly newbie questions, this one is
concerning programm style/techniques:
As my application develops, my AppController class files grow bigger
and bigger. Usually I would try to divide the appropriate stuff up
into appropriate files, but it seems as though common standard in
Cocoa is to use the main controller file for anything. For example:
AppController is the datasource and delegate for my TableView as well
as for my NSBrowser object.#
With all the tableview delegate methods and drag and drop methods and
nsbrowser delegate methods, AppController becomes more and more loaded
and confusing.
But when I consider using seperate files, it seems to me that the
communication makes things even more complicated.
What should I do? Put everything in the AppController or use as many
classes as possible?
My preference is to use the Model/View/Controller design.
Most of the work and features that make your application unique should
be in the model.
It should be possible to present the model to users through any number
of different views (user interfaces) including command line, scripting,
and multiple GUIs.
The role of the controller(s) is to map between the Views and the model.
If there is too much code in the controller layer, you are definitely
doing something wrong IMHO.
You might consider separate table view controller and browser
controller objects. They both presumably reference the same model
which is where all of the interesting code resides. The only
information the controllers need is a pointer to the relevant model
object(s). You can instantiate the controllers in IB if you want and
wire the table and the browser to the appropriate instances (for data
source and delegate connections). The controller classes themselves
probably don't need to know anything specific about specific table and
browser objects.
Logic for things like selecting an object in a browser causing a change
to the contents of the table or disabling other controls etc. is not
really part of the controller layer IMHO. Rules about mutual exclusion
of data and the significance of selection changes are probably
fundamental "rules" concerning the meaning and logic of the model and
such "rules" probably apply no matter what user interface is presented.
Therefore, such rules belong in the model and not the controller layer
IMHO. Instead of hard coding such rules in the controller layer,
consider providing model methods like -
(BOOL)deleteOperationIsApplicable that are called by the code that
enables or disables the delete button/menu item. Then the model can be
smart about what it returns from the method based on rules known only
to the model. When a script tries to delete an item, the same method
in the model is used to enable or disable the script operation...
Similarly, the model might send a notification if some change to the
model invalidates previously returned data. For example, if changing
the selection in a browser requires the content of a table to change,
the following things should happen:
1) The controller for the browser is notified that the selection
changed.
2) The controller for the browser calls a method in the model layer
3) The method in the model layer changes the model state and sends a
notification of the state change
4) The controller for the table receives the notification of a model
state change and causes the table to be refreshed
5) Because the table controller is the data source for the table, the
table asks its controller for new data which the controller acquires by
asking the model.
In this sequence, the two different controllers know nothing about each
other. You are free to change the table into some other user interface
item at a later time and it has no effect on the browser and visa
versa.
The change to the model's state is reflected in the table even if the
model state change for some reason other than a selection in the
browser. A menu item, button, script command, etc. may have caused the
state change.
The separate controllers are likely to be very small and simple.
The logic about model state change means is kept within the model and
can be reused with multiple user interfaces.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.