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: Keith Blount <email@hidden>
- Date: Sat, 22 Jan 2005 08:26:08 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
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:
This email sent to email@hidden