Re: Cocoa patterns?
Re: Cocoa patterns?
- Subject: Re: Cocoa patterns?
- From: brian hook <email@hidden>
- Date: Sun, 26 Aug 2001 17:09:38 -0700
At 12:59 AM 8/27/01 +0200, Georg Tuparev wrote:
- 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.
This makes eminent sense. I assume you're talking about something like
using the Currency Converter app within the Travel Guide app in Learning
Cocoa? So in this case I should concentrate on making one of the smaller
editors to get up to speed on basic Cocoa issues, then do a second editor,
then try to integrate them within a larger workspace?
- 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.
Sounds like a good idea, although I haven't seen any docs on loadable
bundles yet. I'll dig around the Apple developer docs.
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.
I assume you're referring to the original design patterns book by Gamma (?)
et. al.? I haven't read that one yet, even though I know it's been one of
the trendiest books for the past 10 years (along with Extreme Programming,
which I also haven't had the time to read). If that's the one then I'll
definitely hunt it down and start reading.
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...
This may be a case of necessitating "unlearning" the crap that MFC and
AppWizard on Win32 kind of teach people. I had assumed that since IB
generates files for me that any radical changes done to a UI via IB would
require new source file generation, thus destroying existing source. I've
been also assuming that the MVC paradigm minimizes a lot of this damage by
isolating the damage to the "V" part, which ideally should be trivial to
re-implement since the real work happens in the "M" part. Does this sound
right?
Thanks a ton!
Brian