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: Fri, 21 Jan 2005 10:40:10 +0000
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 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