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: Fri, 21 Jan 2005 11:30:25 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Many thanks for your reply, much appreciated - and
very helpful. Sounds like I have a *lot* of rewriting
to do. I had been trying to respect the MVC paradigm,
but my knowledge of this was based on introductory
books (Hillegass and Davison) and tutorials. Thus I
have all of my views and all of my model data in
separate classes, but my controller layer is where
things have got out of hand. Following your mail, I
have started to read up on MVC in the docs again,
which went over my head when I was starting out last
year. I now realise that I have got my NSDocument
subclass doing everything, when it should only be
handling the model data while I use an
NSWindowController subclass to handle the document
views... (I guess I then set my document's window
controller to the new window controller subclass, or
vice versa.) I had just left everything at the
default setting for a document-based app, which I
guess is set up for small projects by default.
20 categories was a bit of an exaggeration - it is
more like 9 (still too many), and some are doing silly
things like only acting as the delegate of the split
view in order to set its width and constraints (which
should be done by the window controller instead, I
guess). But my app still has a long way to go and I
want to sort this out now.
I have downloaded Shiira and AppKiDo and am looking at
how they do everything - many thanks for the links. I
have also started looking at the nib files of other
apps to see how many controllers they use - very
educational.
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?
Many thanks again for your help and thorough reply,
All the best,
Keith
--- Jeremy Dronfield <email@hidden>
wrote:
> On 20 Jan 2005, at 8:04 pm, Keith Blount wrote:
> > I thus
> > broke MyDocument (yes, I need to rename it to
> > something more meaningful) into a number of
> categories
> > (probably nearing 20 now), such as MyDocument
> > (OutlineView), MyDocument (Toolbar), etc, each
> dealing
> > with different aspects of the document.
> >
> > Is this good practise, or is this (as I suspect it
> > might be) a bad use of categories?
>
> Categories are a useful and perfectly legitimate way
> of dividing up a
> class implementation. However, if your document
> class is so large it
> requires 20 categories to make it manageable,
> something is seriously
> wrong.
>
> > Should I be using
> > multiple controllers instead?
>
> This is almost certainly what you should do. Have a
> long, hard think
> about your application's MVC structure, and begin
> dividing it up into
> "areas of responsibility".
>
> > That seems the more modular approach, but then all
> of
> > my controllers would need to talk to one another -
> for
> > instance, if the user selects something in the
> outline
> > view, that informs the tab view which subview to
> > display, and the subview what information to
> display,
> > which is why I at first thought the controllers
> route
> > might be more complicated as they would have to
> know
> > about each other anyway.
>
> Nothing wrong with that. And if you have a situation
> where class A
> needs to know when something changes in class B but
> it doesn't seem
> appropriate for them to "know" about each other, you
> can always use
> notifications.
>
> > This is probably a fairly basic question, but it's
> not
> > something that is covered in any of the books,
> > examples or tutorials I have read because they all
> > deal only with short examples rather than large
> > projects.
>
> It's reasonably well covered in the MVC
> documentation, but of course
> that's all a bit abstract. For concrete examples,
> try studying some of
> the many largish open-source projects available
> online. Off the top of
> my head, a couple of good examples are Andy Lee's
> AppKiDo and the
> Shiira project (Safari-imitation browser):
>
> <http://homepage.mac.com/aglee/downloads>
> <http://hmdt-web.net/shiira/index-e.html>
>
> > Basically, I am just asking what is good
> programming
> > practice in Cocoa for splitting up very large
> projects
> > into managable chunks of code.
>
> Well, it's essentially a combination of personal
> preference,
> understanding MVC and basic common sense. Think of
> your classes as
> employees within a company - each has its special
> areas of knowledge
> and responsibility; some deeper and/or broader than
> others. In your
> document class, the CEO is doing everything, from
> managing the company
> to checking deliveries and making the tea.
>
> Hope this helps.
>
> 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!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
_______________________________________________
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