GigsVT's Journal: Why OOP sucks.

I know what you are thinking, "How can you pick just one reason why OO sucks?". Well, let me preface this by saying: this is just one of many reasons. It just happens to be the one I'm think about today.

OO assumes the programmer can design well right from the start, yet lures the beginning programmer into thinking they are making meaningful abstractions, when in reality their code is crappy and poorly abstracted.

Early "optimization" of abstraction can lead to serious problems. By forcing guesswork abstraction into the initial design, OO causes this premature optimization of abstraction. This causes more refactoring later on, or more commonly, the code just grows unmaintainable as the classes and methods become less and less meaningful.

In an ideal world we could draw nice charts and then code them into the computer and everything would be planned and would work. Unfortunately for non-programmers that want a piece of the pie pretending to be a "software designer", it doesn't work that way.

Software development is a best realized as highly iterative process, with a tight loop. OO discourages this good design by forcing abstractions before they can be meaningfully made.

well d'uh

[mekkab]

OO^W Programming assumes the programmer can design well right from the start, yet lures the beginning programmer into thinking they are making meaningful abstractions, when in reality their code is crappy and poorly abstracted.

Fixed that for ya.



Software development is a best realized as highly iterative process, with a tight loop. OO discourages this good design by forcing abstractions before they can be meaningfully made.

First off, while it may be development, OOP is not software "engineering" (a pseudo sc

Re:

[GigsVT]

I can respect that, but in my experience, that big rewrite never gets done in many cases.

That's why I prefer a highly iterative "tight loop" process of design implementation. API can still be king, but if you take OO out of the picture, the API is no longer an undue influence on the actual abstraction of the code.

You have data inputs and outputs, data is data and code is code. The data inputs and outputs are your API, and your code is your code.

This is starting to meld into one of my other big problems wi

Re:

[mekkab]

I can respect that, but in my experience, that big rewrite never gets done in many cases.

True. I spent years trying to figure out how little code could be written to get some desired behavior.

But then a year and a half ago I started working for the middle-ware team that just up and re-writes EVERYTHING. They have a development mindset, not a maintainance program mindset. I think second line management complains about them but they do what they want. It's truly inspiring. And I've taken that attitude on

Re:

[GigsVT]

Don't you wind up introducing the same bugs over and over?

The normal argument against that is that you wind up throwing away lots of subtle logic that works around some quirk, and then forget about it, until possibly it's too late.

Re:

[mekkab]

Don't you wind up introducing the same bugs over and over?

Nope; not if your testing suite is honed enough to test for those quirks.

/wrote test plans that probably make the current developers cry