Anti-OOP... stupid?

[Timon Gehr]

On 02/15/2012 12:12 AM, H. S. Teoh wrote:
> On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:
>> [...]
>> It does not hurt at all if your code base is more flexible than
>> necessary.
> [...]
>
> This needs to be taken in moderation, though.
>
> I've had to work with code that was unnecessarily flexible. (I.e.,
> over-engineered.) So flexible, in fact, that almost none of us knew how
> to use it, and the code ended up deteriorating into a morass of hacks
> attempting to bypass an overly-general framework that nobody understood.
>
> One particularly bad example was that part of the system had a whole
> hierarchy of database-access classes, intended to replace having to
> write SQL directly. The problem was that it was so poorly documented,
> and so difficult to understand, not to mention requiring a instantiating
> a whole bunch of objects just to do something as simple as "SELECT *
> FROM some_table;", that eventually people just resorted to writing a
> function for executing SQL directly, thus bypassing the entire
> over-engineered mess.
>

Directly executing SQL is a much more flexible approach ;).

> And that was only a small part of it. There were other beautifully
> designed, fully OO, and fully generic classes, that accomplished
> everything from the most trivial of tasks to the most advanced
> high-level abstractions. Like the IPC mechanism, for which at one point
> I had to write code to get through *six* layers of abstraction just to
> call a single function. One layer of which involved fwrite(), fork(),
> exec(), and fread(). Such was the result of the original code base being
> much too flexible than it needed to be.
>
>
> T
>

For what I am concerned, flexible means *simple* to adapt, not that the 
existing code is so bloated and general that it does not need to be 
changed in order to implement a new functionality. In fact, I'd argue 
that such a design is inflexible: All new code is assumed to follow the 
bounds of the legacy code base.