Russ P. a écrit :
(snip)
Wait a minute. Aren't the guy who just took me to task about the
definition of functional programming? So the definition of functional
programming is written in stone, but the definition of OO programming
is written in smoke?
Well, actually, the answer is mostly "yes". Functional programming is
based on a (mathematical) theoretical ground about calculation (google
for Alonzo Church and lambda calculus), while OO is originally nothing
more than a way to implement finite state machines with an imperative
language. OO *is* imperative programming (which is itself also well
defined).
Just for the record, I really don't care much about the definition of
OO programming. I brought it up only because someone tried to claim
that "enforced" encapsulation
data hiding.
is a terrible idea. Well, as far as I
can tell, the majority of OO "programmers" (and software engineers,
software architects,
playing buzzword bingo ?
etc.) seem to think otherwise. Maybe they are
wrong -- but I seriously doubt it.
The first OO languages (at least the second one - Smalltalk) used
data-hiding to clearly emphasize the "black box" nature of objects and
the use of messages as the main (only in the case of Smalltalk) support
for control flow. Remember than by that time, lost of programs where
still mostly relying on *global* state changes. IOW, it has a strong
educative value then...
Following "OO" languages - mostly C++ and Java - kept this "rule" like
it was a sacred cow (but mostly forgot about the more important points
of 'everything is an object' and message-passing as main control flow).
Then everyone started considering this as "fundamuntal", and here we are
years later with one more cargo cult, when years of experience prove
that it's not - at least from a practical POV.
Once again, the important point is that there's a *clear* distinction
between interface and implementation, and that you *shouldn't* mess with
implementation. But what, some people think programmers are stupid, and
so they hire stupid programmers, so they need b&d languages to protect
stupid programmers from themselves - which just doesn't work, since
*nothing* is idiot-proof. Heck, how many Java "OO" programs with dumb
getter/setter pairs for _each and any_ attribute ?
As I said before, enforced encapsulation may not be appropriate for
every application, but it is definitely appropriate for some.
No. It is appropriate for dummy managers hiring dummy programmers. The
project's size and domain have nothing to do with it.
Not
every door needs a lock, but certainly some do.
You only need locks when you don't trust your neighbours.
--
http://mail.python.org/mailman/listinfo/python-list
