• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Fwd: Design, Architecture, and Thought Processes (Was Re: shopping carts)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Prev by Date: Re: Webobject Windows Trial
  • Next by Date: Fwd: Safari: Using a WOSubmitButton inside a JSConfirmPanel
  • Previous by thread: ModelViewController Song from WWDC2003
  • Index(es):
    • Date
    • Thread