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: "Adam Chan" <email@hidden>
- Date: Thu, 28 Aug 2003 13:35:49 -0600
I like argumentative tone as long as it has points. Productive discussion is
what make me grow, which is why I'm here.
"Many people spent 10 years programming C++ still have no clue about what
OOP is about", my OOP professor's open statement in my first OOP lecture in
college long time ago. So true...
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.
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).
That is, if your project is small, e.g., you are the one and only one
developer, and the project is a one time deal that once it is done no one
will ever touch it again, than I would say forget about OOP, do whatever
that make it work peroid. On the other hand, if it is a group project and
the project will continue to grow and you don't do OOP (spend the time on
design), hehe...good luck, let's see what'll happen in the long run...
Many times I told my fellow developers that you simply can't name a class
where it doesn't do what it is named for, or put methods/variables that
shouldn't be in that class (isn't it the very basic OOP concept). They said,
why? it works! Oh well, what else I can say when you are surrounded by these
kind of developers (yes, many of them are MS in CS).
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.
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?
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).
> Well, if you don't mind the argumentative tone, if there are so many
> good books how come there aren't so many good engineers? I don't think
> OOP is as natural as its proponents make out. Mind you, it's always
> been natural to me but I don't think that makes me superior in any
> way. Just weird :-)
> I guess I would say that the emphasis on real world modeling that most
> OOP books take is wrong. For most of what we do we are not modeling
> real
> world things. What is the real world analog to a single sign-on system?
> Or how about search engines? What's the real world analog to a search
> engine?
> This starts out with
> Likely, if you've ever tackled any kind of difficult programming
> problem, your design has included groups of functions that work on
> a particular kind of data--implicit ``objects'' without the language
> support.
>
> Almost none of the developers I've worked with view the world this way.
> They
> would all be happy writing one stovepipe function to do the whole task.
> In fact,
> the few times I've gotten them to split a problem up, two or three
> revisions later
> they've crammed it all back together. "It's just so much easier to
> understand this
> way."
>
> Maybe we need a series of books like
> Design Pattern Cookbook for C
> Design Pattern Cookbook for Perl
> Design Pattern Cookbook for C++
> Design Pattern Cookbook for Java
> etc
> That's kind of an ad hominem attack; e.g. they're too fat/stupid/lazy
> to do it the
> right way.
>
> If the developer doesn't see OOP in all its glory then there must be
> something about
> OOP that obfuscates the glory. Look at Perl. About the butt-ugliest
> thing there
> is in just about any metric imaginable except one: it makes developers
> feel
> productive. How come OOP doesn't make people feel productive? Note,
> I'm not
> saying that the OOP guys are not productive. Just that nonOOP guys
> feel that
> OOP slows them down. It's perception, not reality.
>
>
> That's not true anymore. All the good jobs are going to India :-)
> Maybe the
> only ones left will be the ones who care.
_______________________________________________
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.