Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- Subject: Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- From: Arturo Pérez <email@hidden>
- Date: Thu, 28 Aug 2003 20:57:29 -0400
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.
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.
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, often we are not modeling real world things, but hey the
objective is
to model (divide and conquer) a complex problem into human
understandable
abstraction.
Exactly. But that's not necessarily the same as maintainable and
reuseable.
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.
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."
-------
WebObjects in Philadelphia. You want a cheesesteak with that?
http://webobjects.meetup.com/
_______________________________________________
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.