Re: Cocoa patterns?
Re: Cocoa patterns?
- Subject: Re: Cocoa patterns?
- From: Georg Tuparev <email@hidden>
- Date: Mon, 27 Aug 2001 00:59:18 +0200
Brian,
I would begin with several more general suggestions:
- Do not start with a big project. Start with something smaller. A
concrete document editor would be probably a good place. Wait until you
get the "aha" feeling. From your email I've got the strong impression
you are just not ready to start the big thing, and I bet if you dig
down it is not because of technology, but probably because you are not
comfortable with re requirements.
- Use loadable bundles to achieve modularity. For instance, when you
finish the first simple editor, move the domain (model) classes to a
framework, and wrap the controller and the viewer in bundle.
- In parallel of the writing of the bundle start working on your
"monster" application. Make it very simple, let even bundles configure
their own menu items.Do not make any explicit references between the
application classes, and between the bundle classes. If you need to let
them talk to each other, do it using notifications (but do not misuse
them -- they could be a major performance killer). In that way you will
achieve maximum orthogonality between the modules.
- Refactor all the time. Do not be afraid of trashing sources, or making
major design changes,
On Sunday, August 26, 2001, at 07:21 AM, brian hook wrote:
>
I'm not sure the right way to architect the app in terms of MVC. My
>
naive way of looking at it is that I'll have a "metacontroller" which
>
possesses several multiple document controllers. The application
>
workspace is the metacontroller and, in turn, controls the various
>
specific object editors through their own controllers. Each type of
>
object editor adheres to a multiple document MVC paradigm. Does this
>
sound like the right path?
>
In general it is ok. A good candidate for the "metacontroller" is
probably the Application delegate object. But avoid explicit knowledge
(API sharing) between the metacontroller and all other document
controllers. Use notifications instead.
>
On a slightly related note, and the reason for the subject line, is
>
that I assume there is a repository of information about design
>
patterns in Cocoa, i.e. stuff the old-hands use matter-of-factly that
>
the newbies don't know about.
>
Not that I know of. But the Design patterns book by the Gang of Four is
very strongly influenced by the predecessor of Cocoa, called NeXTSTEP.
And if you wait for a month or two, I will publish parts of my book (in
preparation) on my website. It will include some useful patters.
>
For example, how do most people use IB in a production development
>
environment? Do they tend to use it early to generate files then don't
>
touch them, or do they commonly rearchitect the UI throughout the
>
project and deal with any side effects as they crop up?
Different people have different styles. I use IB all the time. Very
early in the project as a prototyping tool, later to generate the fist
simple interfaces. Once this is done, I normally edit the header files
and let IB synchronize them. This technique is actually more efficient
then to do everything in IB and let it create the skeleton of the source
files. At least for me. But as I told, you, it is a matter of taste and
team style. BTW, where do you see "side effects" in using IB during
later phases of a project? I never seen one...
I hope this helps a bit
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196