Re: Cocoa patterns?
Re: Cocoa patterns?
- Subject: Re: Cocoa patterns?
- From: Georg Tuparev <email@hidden>
- Date: Mon, 27 Aug 2001 17:28:04 +0200
Brian,
In general you are on the right track.
One advise I forgot to give you - also very general one - is to get a
good book on C, and another on Unix. My favorites are:
"The C Language" by Kernighan & Ritchie, and
"Advanced programming in the Unix Environment" by Stevens.
You need them in more abstract way. As an example, you will get much
better feeling of how the ObjC runtime system is working after
understand how pointers to functions work... In a way everything will
make just much more sense.
On Monday, August 27, 2001, at 02:09 AM, brian hook wrote:
>
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?
>
exactly.
>
> - 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.
>
Check NSBundle (in Foundation + AppKit additions). There are some
undocumented methods like plugInsPath that are very helpful. If you run
in trouble do not hesitate to ask me for help...
>
> 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).
>
Read them! All six of them. It will be a very good investment! But start
with "Pragmatic Programming". After you finish them, you will feel that
you are in control of your software projects.
>
If that's the one then I'll definitely hunt it down and start reading.
>
This is the book I was mentioning. But do not make the mistake to design
towards any specific pattern. If after several iterations and a lot of
refactoring you feel like your code start looking like one of the
patterns make a final refactoring effort to clean up the lose ends and
give right names ... so other people can read your code better ... and
you can remember it longer.
>
> 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?
>
The only items that needs to be synchronized are the actions and the
outlets declarations. If you develop a consistent style of grouping them
neatly, and tagging them with IBAction and IBOutlet, you will hardly
ever run in any trouble, even if you are making significant UI or design
changes.
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196