I can't take credit for it, though. Though Meyer talks about design
by contract, that's not quite the same thing. This particular
approach to objects something I encountered in "Design Patterns
Explained" by Alan Shalloway and James R. Trott, an excellent,
thought provoking book.
I don't think I entirely agree with you when it comes to structured
programming (or maybe I do?) Certainly, this is a good guiding
principle, but you end up building knowledge of the larger context
into parts of the program that you would rather not depend on this
kind of thing. For example, I wrote a function to recursively
traverse a file entry, visiting each field and subfield. the first
parameter was the file number and the second the field number. For a
file entry that's enough, butt when you descend into subfiles you
have to worry about *which* subentry you are processing, so I added a
third parameter that would only be used in recursive calls and never
used by the (outside) caller.
Or, to use a more traditional example, think of The Towers of Hanoi.
Conceptually, a recursive solution is all but trivial, but once
you've moved one or more disks to the destination peg, your program
has to "pretend" they are not there and solve the smaller subproblem.
Unfortunately, your program doesn't only have to "know" it's solving
the Towers of Hanoi puzzle, but it has to "know" that at each stage,
certain disks have to be ignored.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Before one gets the right answer, one must ask the right question."
-- S. Barry Cooper
On Jul 12, 2005, at 3:22 PM, Ruben Safir wrote:
On Tue, 2005-07-12 at 17:29, Gregory Woodhouse wrote:
Yes, but if you think about object oriented programming as just being
about encapsulation, then I think you've missed the point to some
extent. I like to think about it as programming in space rather than
programming in time. Another way of looking at it is that it isn't
just about decentralization of function (encapsulation) but
decentralization of responsibility. It's not just a matter of
creating components that "know" how to do a particular job, but of
creating components who only need be concerned about doing that
one job.
Rather poetic and also all true of structured programming. (except for
the programming in space part which I'll be gracious enough to just
ignor :) )
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
