object-orientation is a nice idea... it really is. the concepts are rather sound. and it's relatively easy to explain to others, and it provides a nice, obvious, basic decomposition into different segments of work that can easily be parceled out to individuals, thereby making it easy to command others in a clear, concise manner that may not involve fully explaining the overall design.

in short, it's a paradigm for managers and for executives to feel good about, because the paradigm does all the thinking for them.

of particular interest is the word object, because it's so generic, every one has their own vision of an object. it's something that everybody knows but they can't describe to others. it's also good for the computer, since the computer thrives on generic stuff. and everybody knows that's the common fallback when their design fails. i think this is why everybody likes the idea, because everybody is instantaneously comfortable with an "object" but yet, nobody questions that nobody else does not share their mental model. the good thing is that an object can only be so... varied between people, that their mental models usually are close enough to get things done.

patterns

the issue i have with object-oriented languages is that it adds an extra layer of code and logic and understanding that is purposely there simply to complicate the design. "astronaut architects" who live in the ivory tower call these things "patterns". systems programmers and other lower-level people call these things "designs".

consider a common class of *nix programs, the "filter" program. their job is to simply accept some input on standard in, modfy it, and place it on standard out. the program has a fairly obvious design, it can be split up into three different components, amely:

if we do the "right thing" and object-orientify this, we add another layer of code, the infrastructure layer.