Fwd: Design, Architecture, and Thought Processes (Was Re: shopping carts)
Fwd: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- Subject: Fwd: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- From: "Nathan C. Hampton" <email@hidden>
- Date: Sun, 31 Aug 2003 19:47:52 -0500
Okay, this got held up in cyberspace....
Begin forwarded message:
From: Nathan Hampton <email@hidden>
Date: Fri Aug 29, 2003 12:50:00 PM America/Chicago
To: email@hidden
Subject: Re: Design, Architecture, and Thought Processes (Was Re:
shopping carts)
On Thursday, August 28, 2003, at 07:57 PM, Arturo Pirez wrote:
On Thursday, August 28, 2003, at 03:35 PM, Adam Chan wrote:
Ok, to answer your question "if there are so many good books how
come there
aren't so many good engineers?" May I ask you back, how many music
composers
like Beethoven and Chopin ever existed in this world? We are talking
about
software design, and "design", at first, requires talent. I just
don't think
one can become Beethoven by reading a few books :) That is my point.
Well, I'm not sure that one can become Beethoven without having been
born
Beethoven. Or at least a proto-Beethoven. How about we aim a little
lower?
Let's skip the talent portion of the show. It's too hard to get by
one's
own efforts.
I agree. Speaking as a musician, it wouldn't have mattered if I had
taken every music theory class in college. I still wouldn't have been
a good composer. (Or even a competent one, come to think of it.) On
the other hand, two classes in Java and some good books have made me a
competent programmer, a claim with which I am comfortable because I
know where my limits are. (That said, I rarely hesitate to stretch
them.)
Going back to the OOP topic, I believe most people don't realize
what OOP is
about--maintain and reuse (just making something work isn't what OOP
for).
...
Many good points. I agree and disagree. I personally don't use OOP
to maintain
and reuse. I use OOP because it makes what I'm doing easier to
understand. I
write code piecewise. And that piecewise nature is easiest to do
using OOP.
Yes!! Don't we all get taught that as kids? If it's too big, make it
smaller. If you can't comprehend the whole thing, start with a piece
you can comprehend and go from there. The OOP concept of abstraction
(that is, you don't necessarily need to know how that class does
something, as long as you know it will produce the results you need)
is essentially an extension of this principle.
It does lead to very maintainable and reuseable code. But problem
with shooting
for reuse from the start is that one usually does not know what other
developers
need. This causes a great deal of analysis paralysis.
Yes and no. I don't initially go about planning for reuse, but when I
come across a function that is obviously going to be useful later, I
break it out so I can reuse it when the time comes. (I actually have
a 'Utilities' class just for that purpose.) When I'm working on a
later project, if I come across a function similar to one I've already
made, I'll go back and see if I can break out the parts of it that I
need so I can use it both places. In my opinion, reusability is more
"oh, I did this already; no sense doing it over" than "I need to make
sure someone can use this later." (Exceptions, of course, occur)
Maintainability is another ball of wax altogether, and is more closely
related to 'easier to understand' than reusability. In well-designed
OOP, it's relatively easy to isolate the location of a change or
error, reducing the amount of code that needs to be checked or
modified. I don't know anyone who wants to troubleshoot 1000 lines of
code when troubleshooting 100 lines will solve the problem just as
effectively.
Say, an example that someone mentioned before, department<>employee,
a many
to may join. When we model it, wouldn't it be better (more easy to
understand) to have
aDepartment.employees()
anEmployee.departments()
than
aDepartment.departmentToEmployees().valueForKey("employee")
anEmployee.employeeToDepartments().valueForKey("departments")
Especially in this case we have no use of the join other the join
itself.
Why create the classes/objects? Why not flattern it and let
WebObjects
taking care of the rest?
Most of the people I've worked with don't seem to understand what the
problem is ("I need a department with employees.") They think
"I need an array with some employees." That seems to cause the most
grief to
me.
They taught me in IS classes that this is the whole purpose of systems
analysts: to be 'translators' between the business need ("I need a
department that has employees.") and the programming concept ("The
Department object needs an array of Employee objects.").
Businesspeople worry about business, programmers worry about
programming, and analysts bridge the gap. In smaller organizations
(my specialty), this distinction is frequently only in the mind of a
single person, but it's an important distinction to understand.
To all the developers I met, most are inexperience (they don't give
a damn
to become a better one anyway), a few however have a very wrong
perception.
These self-educated hard working fella believe the best solution to
slove a
problem is the most complex one. Since their solution is hard to
understand,
it looks cool (they think so I guess).
I don't think that's true. Nobody likes complicated answers. I
think they
just don't know any better. "Everything looks like a nail to a man
with a hammer."
This is just a training issue. The concept 'if it doesn't meet the
business need, there's no point in doing it' needs to be drilled into
the heads of every analyst, every developer, and every programmer.
Unfortunately, far too many training programs have fallen into the
'teach them programming and shove them out the door' trap.
--Nathan Hampton (email@hidden)
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.