Re: Program structure
Re: Program structure
- Subject: Re: Program structure
- From: Joe Osborn <email@hidden>
- Date: Thu, 2 Jun 2005 09:13:32 -0500
Welcome to Cocoa!
I trust you've read The Objective-C Programming Language and the
other relevant starter documentation on design? If not, now is a
great time to do so.
The best thing to do is not to design in terms of windows and
controls - Cocoa can be used for quick application development, but
it isn't a 'put the damn data on the damn screen' procedural RAD
tool. It uses a design paradigm called Model-View-Controller.
Further, Cocoa is an object-oriented framework which emphasizes
interactions between more-or-less autonomous objects, and not the
flow of data from one place to another. You program by sending
messages to objects. It's very easy for a new developer to start
shoving every bit of code into a "SomethingController"; stand guard
against that, and it was wise of you to notice the threat. But don't
make your divisions among arbitrary user interface lines.
That said, for each major mode of viewing your model data, you'll
likely want a separate controller. A controller is the part you've
seen already, the seemingly procedural part, that maps data from the
model to something a view can use, and input from the latter to
changes in the former. A controller is usually set to be the
'target' of various controls; when their actions fire, the
controller receives the message named by the selector set up in IB or
via setAction:.
Please remember that the GUI of a program is just one perspective on
its data, and GUI design should probably not drive the code's
design. (If you're looking for something that -should- drive you
design, I find that Test-Driven Development(http://www.c2.com/cgi/
wiki?TestDrivenDevelopment) can make for some excellent application
designs, especially when refactored post-facto towards various design
patterns[http://www.c2.com/cgi/wiki?DesignPatterns]. You'll of
course want a unit testing framework like Sen:Te's OCUnit or ....
some other person's UnitKit{Sorry, author of UnitKit! I can't
remember your name!}.)
If you're at liberty to discuss particular details of your
application, that would be helpful for moving this discussion
someplace more concrete.
__joe
On Jun 2, 2005, at 08.29, Paul Harvey wrote:
<New Cocoa-developer alert!>
Hi all. I've been coding using REALbasic for years, and use PHP
with MySQL in my daily work. I'm all fired up to dig into Cocoa and
have been meaning to for a long time. Now i've started and seen
some positive results, I'm eager to build on my new-found knowledge.
I'm having difficulty working out where to place code. In
REALbasic, blocks of code usually sit with the relevant control.
For example, the Action method of a button holds the code that
would run when the button is clicked, or it would call a function
that did the work.
In Cocoa, controls send messages, so the method can know who called
it and ask the control/object for more info if required.
To the established Cocoa developers, how should I go about
organising my source code? I can see -- if I'm not careful -- one
file.m file becoming unmanageably long with all functions/methods
held in it. Should I just create different .h/.m files for
different parts of my application as I understand it? Or is it more
likely that each window created in Interface Builder has its
own .h/.m files so I should put the code in each of those?
Thanks for your help and patience.
--
Paul Harvey
Lead Programmer
email@hidden
Hiddenfield Software
"Creating useful software for Mac OS X"
www.hiddenfield.com
_______________________________________________
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
_______________________________________________
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