Many thanks again for the helpful reply.
Looking at the examples you linked to and at the docs,
although restructuring will be painful, hopefully it
shouldn't involve rewriting the whole app after all.
My main error, I think, is that I've done everything
in my document subclass. If I split what's in there
between that and a window controller subclass, I
should hopefully be heading in the right direction.
Looking at your list of methods of communications
between classes, things aren't as awry as I had
feared. All of the model and view classes are separate
and modular, using notifications where necessary, and
I have separate controllers for other windows
(preferences and suchlike). And a document and window
controller subclass will be able to communicate
easily; I can then put view delegate methods into
window controller categories as Shiira does.
Thanks again for all the help,
All the best,
Keith
--- Jeremy Dronfield <email@hidden>
wrote:
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 you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to email@hidden