I said that a well-factored application should be easier to put a
Cocoa or Carbon interface. (That statement goes for both Unix and
Windows applications, by the way. It's great that Apple has this
list for porting Unix applications to Mac OS X; will Apple also be
creating a list for porting Windows applications soon?) But what is
it that makes an application well-factored?
Primarily, a well-factored application has as complete a separation
as possible between its "engine" and its interface. What this means
when it comes down to coding, though, can sometimes be up for grabs.
I interpret this separation to mean that the application uses a true
Model-View-Controller (MVC) architecture. The actual data model used
by the application is completely separate from any interface to it,
and there is a controller layer that ties the two together. When
porting such an application, the controller layer provides a place to
put your modifications for other systems. Or if the data model is
complete enough -- i.e. it implements all of the necessary business
logic for the application -- the controller layer itself might even
be replaceable.
Practically speaking, this means that lots of applications aren't as
portable as they could be. For instance, I just had to add a feature
to an application. The application in question doesn't always follow
MVC, and that made it more difficult to add the feature than it
otherwise would have. In particular, it used interface elements --
popup menus, checkboxes, and text fields -- as data storage rather
than simply having them reflect and modify the state of a separate
data model.
This is also a stumbling block I've seen with people learning Cocoa.
They want to know how to put data "in" and get data "out" of an
instance of NSTableView. NSTableView doesn't work that way; instead,
it asks a data source for the information it should be displaying on
demand, and relies on NSCells in its contained NSColumnViews to
actually display and edit the data. This architecture forces you to
follow MVC much more closely than many other frameworks, but it
requires you to thing at a slightly higher level about your
application's design.
If you're starting with an application that isn't all that well
factored and you have the ability to make significant changes to your
starting codebase, one technique that might help is "refactoring."
Refactoring involves going through an existing codebase and making
mechanical transformations on it. You're not adding or removing
features, but rather doing things like changing variable names to be
more readable, putting repeated code into its own methods, promoting
duplicated methods into superclasses, and so on. The canonical book
on refactoring is "Refactoring" by Martin Fowler. There are plenty
of web sites on the subject, and refactoring has been strongly
embraced by the eXtreme Programming and Agile Development movements.
-- Chris
--
Chris Hanson | Email: email@hidden
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
unix-porting mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/unix-porting
Do not post admin requests to the list. They will be ignored.
