Anti-OOP... stupid?

[James Miller]

On 15 February 2012 12:12, H. S. Teoh <hsteoh at quickfur.ath.cx> 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.
>
> 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
>
> --
> Why are you blatanly misspelling "blatant"? -- Branden Robinson

Basically, flexibility is good, but you have to make sure you are
actually writing a program, not a platform or framework, or worse a
COBOL. (COBOL being COmmon Business-Oriented Language, intended for
"business people" to use, and let programmers get back to writing
device drivers <.<)