Re: Multiple controllers vs multiple categories (or tips for large projects)
Re: Multiple controllers vs multiple categories (or tips for large projects)
- Subject: Re: Multiple controllers vs multiple categories (or tips for large projects)
- From: Jeremy Dronfield <email@hidden>
- Date: Sat, 22 Jan 2005 11:15:56 +0000
On 21 Jan 2005, at 7:30 pm, Keith Blount wrote:
The only thing I remain confused about is the best way
to communicate between my controllers - are
notifications the best way, or should I look into
bindings as suggested by Andreas (thank you Andreas)?
Or should I just create them all in one place and make
sure they have pointers to each other, so that they
can call on one another directly?
I don't have any experience with bindings, so can't advise on that. (I
would suggest, though, that you might risk mental health problems if
you try to learn bindings at the same time as re-structuring your
project. But don't take my word for it.)
The "best way" for classes to communicate with each other depends
entirely on what they do, whether their "areas of responsibility" are
adjacent to or dependent on each other, and how much they consequently
need to know about each other. Ask yourself questions:
Does MyClassA merely need to know that there is a class called MyClassB?
Does MyClassA need to know about and access MyClassB's instance
variables?
Does MyClassA need to send messages to MyClassB, ordering it to perform
certain actions?
Does MyClassA need to contain an instance of MyClassB as an instance
variable?
Does MyClassA merely need to know when something changes in MyClassB so
that it can perform some (indirectly related) action of its own?
If MyClassA needs to know about MyClassB's instance variables and
methods, does MyClassB need to know anything at all about MyClassA?
I'm sure there are other considerations I haven't thought of. There is
no graven template for designing a program; just the general guiding
principle of MVC. The hallmark of a well-designed program is that its
structure breaks down logically and economically, is easy to maintain
and easy to extend.
Again with reference to example projects, I've found that the best way
to get to grips with their structure is to pick a single, central
program action (e.g. selecting and opening a bookmark) and trace it
through the classes which are involved in executing it and the classes
which are indirectly affected by it.
One final word. In re-structuring your existing project, you may not
end up with ideal results, since you'll be working with code which has
been written in the context of your original (lack of) design.
Therefore, your new design is likely to be determined by the existing
code and won't necessarily be much of an improvement. A better way
might be to work on a new project (either a completely new application
or an all-new rendition of the existing one), designed from the outset
with modular MVC in mind.
Regards,
-Jeremy
===================================
SkoobySoft, home of viJournal and Skooby Renamer
email: email@hidden or visit:
http://freespace.virgin.net/jeremy.dronfield/skoobysoft.html
===================================
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden