Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
- Subject: Re: Design for Cocoa (was Re: Can a subclass of NSDictionary do this?)
- From: Neil Earnshaw <email@hidden>
- Date: Thu, 24 Jul 2003 11:02:11 +0100
I've been thinking about your posting and my experience and, for what
its worth, I've have come up with three premises relating to design and
implementation.
1. You can't devise a good design until you have mastered the
vocabulary of your problem space.
Imagine:
a poet trying to write about the G5 without first thinking
about the feelings it arouses (or doesn't).
an architect trying to design a bespoke house without
talking to the clients.
a software engineer trying to design a sonar system
without learning about the physics, mechanics and
maths needed to produce a sonar image.
The trouble with software design is that we're usually asked to come up
with a design that solves a problem we've never encountered before.
Our vocabulary is very poor in the new problem area so we undertake an
analysis of the subject to improve it. Once we literally know what
we're talking about, we stand a chance of producing a good design.
2. You can't build a good implementation until you understand your
building materials.
Imagine:
a poet used to writing in English being asked to
compose verse in French.
a builder used to bricks and mortar being asked to
build a house using a traditional green oak frame
with a lot of high-tensile glass.
a programmer used to C++ and MFC on a Windows
PC trying to build a sonar system in C with VSIPL
on a real-time architecture based on G4 cards.
If the system is even slightly more than trivial, you've got no chance
of producing a good implementation until you've tackled the materials
learning curve. The only way to evade the learning is to hire some
who's already mastered the materials to do the work for you.
3. If you understand the materials, you improve your chances of
producing an implementable design.
Imagine:
a poet who has French as a second language
stands a better chance of composing acceptable
verse in French.
an architect who understands green oak and high-
tensile glass stands a better chance of producing
a workable design for a house in those materials.
a software engineer who understands real-time
signal processing stands a better chance of
designing an working sonar system.
The designer doesn't have to be a master of the building materials, and
the builder doesn't need design expertise. Its the difference between
reading and writing a language. The designer and builder should each
have reading skills in the other's language, though they only write in
their own. Of course, you get people who are fluent in both - it's the
norm in software development. Still, it comes as a shock (it did to
me) when, after years of experience with C++ on PC's, you switch to
Objective-C and Cocoa on a Mac.
I think the great thing about XP is that it encourages you to learn in
bite-size chunks. You bounce ideas off other people and practice
continual revision thanks to refactoring. Its great when learning is a
serious issue on the project. (And, right now, I feel like learning
Cocoa is going to be life-time issue.) On the other hand, if you are
building your tenth sonar system on a platform you've been using for
five years, then what's the point? A design-first plan reusing huge
chunks of knowledge and code has to be the way to go.
Neil
Neil Earnshaw
Consultant Software Engineer
Object Software Engineers Ltd
email@hidden
Tel : 01747 854 852
Mbl : 07870 209 102
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.