Re: Object Orientation is:

[Courage]

Steve Fink once sayd on p5p really wise and funny things: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg01004.html

...
Ok, so I didn't really mean that about information hiding. Dramatic
license. But it is one of the things that bothers me the most about OO
code. A "real OO programmer", when given the task of implementing a
heart, would take a real heart and coat a meter thick layer of plaster
around it, then drill holes down to the aorta and stick tubes in them.
He would tell you how great it is that you can replace the buried hear
+t
with a vacuum cleaner or a rooster without changing anything else. Whe
+n
you complain about the tubes sticking out of your chest and the
wheelbarrow you need to push your new heart around in, he'd quickly
point out that the wheelbarrow is really an advantage because you can
haul around all kinds of other great things at almost no added burden.
...

:)

Courage, the Cowardly Dog

[sfink]

Cool. That's the first time I've ever run across someone quoting me on the web (properly attributed, even!). A slightly updated version is at http://foxglove.dnsalias.org/~sfink/rants/information-hiding.txt, but the passage quoted above is unchanged (and probably the only part worth reading.) But as I say in the pointer to it from my home page:

If you disagree with it, then it's probably more right than wrong for you. If you agree with it (like I do!), then it's most likely more wrong than right. We humans are funny that way.

[agentv]

...this is very funny, but the analogy breaks down immediately when we realize that the heart is a component of a system that is not subject to extension, redesign, or feature creep. (So far at least, who knows what will happen in the age of nanotechnology?)

It's easy to laugh at the idea that encapsulation leads to the possibility that we could replace the heart with a vacuum cleaner or a rooster. But imagine a real-world situation that concerns something almost as dear to many of us, the filesystem.

Most Unix filesystem afficionados are aware that files are based upon a construct known as the inode. (An inode contains all of the relevant information that defines a file with the exception of the file's name.) In order to support the notion of remotely available files through the NFS filesystem, designers had to choose between either modifying the core code in the kernel to make special exceptions for files that are seen in a mounted NFS filesystem, or finding an abstract layer that encompassed all of the things that are common to both types of files.

It would not have been difficult to account for both types of files in the kernel, but then there was this other form of networking that was common in the early days of NFS. A lot of people called this the "sneaker net." People wanted to put floppy disks with PC filesystems into their systems and be able to read them.

So without an abstract representation of the inode concept, there would have had to be changes in the kernel to account for every new filesystem that came along. (So the S5 filesystem, the UFS filesystem, the PCFS filesystem and NFS filesystems were just the beginning of the problem.)

By throwing some plaster around the problem (not a meter thick perhaps, but maybe only a few centimeters), it became possible to support a virtually unlimited number of new filesystem types without much change to the kernel core.

In the end, OO programming is over-hyped, but then so are Tiger Woods, Michael Jordan, and Barry Bonds. This does not detract from their greatness. On the other hand, you probably wouldn't hire Tiger Woods to clean your carpets. A simple Perl one-liner would be a better choice.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

[agentv]

...I fully expected someone to challenge me to demonstrate the Perl one-liner that will clean your carpets.

...All the world looks like -well- all the world, when your hammer is Perl.
---v