I'm over OO.

[drunkenmonkey]

Seriously, I'm sick of it.

I don't understand modern programming's obsession with object-orientation. For goodness' sake, not everything is an object, so why treat everything like one? It's so unnecessarily constraining. Programming is about algorithms and using them to manipulate data. Sure, you may throw objects in the mix as well if you want, but I wish people would stop trying to twist every concept to fit the OOD model. Language designers should focus on implementing real life principles instead of trying to reinvent them.

Even worse is when people start trying to force everything not only into objects but into design patterns. (Java is a torturous example of this.) I feel that programming languages are becoming less intuitive for their users and more and more simply for computer science students to write lengthy, vacuous, and yet seemingly profound essays about.

Object-oriented languages are an annoying fad and are not the future.

(*Dons flame-retardant suit*)

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) and use a few power tools where warranted to make the process go smoother and quicker. Not to mention easier for later upgrades and maintenance.
And please GAWD tell me that by Java you are not meaning JavaScript?!?
I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient.
Granted not everything deserves OO treatment, there is always going to be a place for C code.

[penagate]

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) and use a few power tools where warranted to make the process go smoother and quicker. Not to mention easier for later upgrades and maintenance.
And please GAWD tell me that by Java you are not meaning JavaScript?!?
I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient.
Granted not everything deserves OO treatment, there is always going to be a place for C code.

I am not advocating the use of primitive tools. Merely, I am pointing out that OOP is not the be-all end-all solution to every programming problem under the sun, as its proponents would have you believe. I have nothing against the concept of objects, but designing a whole system to be objects is pointless and unnecessary. It's bureaucratic design. You can easily end up spending more time architecting class relationships than you do actually focusing on code flow and algorithms. And it's also rigid design. Heaven forbid you make a mistake in your initial class relationship chart, or you have to go back and move a whole bunch of code around because class A now needs to inherit from class C instead of B and so method X needs to be replaced with method Y or B::Z is now C::Z and so on. Dropping reusable objects into code is a beautiful thing. Designing a fully object-oriented application is not.

One of the key principles of OOP is encapsulation. Objects are supposed to be able to deal with things by themselves. But what happens when they can't? You've hidden everything away so the object's useless beyond its stated capabilities. Instead of letting programmers deal with problems, OOP shoves them under the rug of encapsulation.

Objects also couple data and functions. This is usually undesirable. We spend a lot of time trying to separate data, algorithms, and presentation. Yet OOP objects couple these together like a ball of Play-Dough.

I am also disgusted by over-abstraction and the propensity of bad OOP programmers to abstract beyond necessity. Abstraction is evil! The more implementation details you hide, the less certainty you have when using code. Sure, it works. But what's the cost? What are the possible side effects? And the more abstraction layers you pile on, the more danger you have of the abstraction collapsing and rendering itself useless [see Joel Sporsky's Law of Leaky Abstractions]. There is a sweet spot between no abstraction and over abstraction.

The same applies to inheritance. Inheritance can be a powerful tool in the right hands. When used with abandon, it wrecks the cohesiveness and maintainability of a system. You will run around for hours up and down inheritance chains looking for that bit of code that's causing a bug that once fixed will cause you to run up and down another inheritance chain looking for another bug.

OOP does nothing but encourage, and in many cases force, programmers to employ facilities such as these which only the best programmers are capable of using wisely; madness ensues. Two years ago I didn't know what it was. Now, after both having used it and having it continually shoved down my throat as the best thing since the proverbial sliced bread, I'm thoroughly sick of it.

(P.S.: I am appreciative of the subtle differences between Java and JavaScript. One is a rigid object-oriented language while the other is a more free-form procedural/object-oriented language. I actually like JavaScript (although I don't enjoy client-side web programming much), but Java is horribly stifling.)


Edit: Moved from Chit Chat.

[MasterBlaster]

So what you're really saying is you hate krappy OOP designs. I don't think anyone will disagree with that.

[RhinoBull]

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) ...

Although OOP was not commonly used it was originated more than 40 (!) years ago. 21st century, eh ?

...I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient...

Procedural language is synonymous for faster (much more faster) processing.

[drunkenmonkey]

Although OOP was not commonly used it was originated more than 40 (!) years ago. 21st century, eh ?

thus the use of (well in this case the 20th century)


and Pen, the seemingly pointlessness of architecting first vs just jumping in and coding is a trap that quite a few programmers fall into.
You are correct you can go to far with OO architecture, however if the project is planned out and you use incremental steps i.e. use case, design, meet with domain experts, code a mode, in two weeks then meet and reflect and make necessary changes; I've found it to be far more productive.

Some things do not need this though you are right, sometimes all you need is a script to get the job done.
We're really comparing apples to oranges here.

[drunkenmonkey]

Procedural language is synonymous for faster (much more faster) processing.

faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.

[RhinoBull]

how about in the long run when there is maintenance to be done?..

So what? What is your concern?

[drunkenmonkey]

So what? What is your concern?

Did you not read the entire post?

faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.
Procedural does not always equate to faster.

[RhinoBull]

Did you not read the entire post?

faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.
Procedural does not always equate to faster.

Try not to confront - otherwise you might be talking to yourself...

[Spacehamster]

I remember (with some sheepish embarassment) my first meeting at my current workplace (3 years ago). It was to discuss a strict programming architecture that we were to apply to every single application we'd ever write - regardless of how big or small it was. As I dimly recall, this involved at least 6 levels of abstraction and over 36 subclasses. It took 2 hours to explain how it all worked.

At the time, I wasn't very enthusiastic about the idea, but back then I couldn't put my finger on why. After reading Penagate's original posting, I realise why - it was OO Design and abstraction gone mad. A perfect example of Architecture Astronauts at work. And another lesson that there's no such thing as a Silver Bullet.

[drunkenmonkey]

Try not to confront - otherwise you might be talking to yourself...

Well I don't know it sounded like you were doing the same. I thought that's how you all talked to each other here?

[kedaman]

Nice to see someone else who hates OOP and thinks it smells
OOP bundles together data and functions - this is highly undesirable and annoying. The concept used in for instance Haskell classes are much more flexible and useful, because the data is abstracted from a class.

However I don't agree, that abstractions are evil - it is OOP that corrupts the pure concept of abstraction, because of all the unnecessary overhead that polymorphism causes, which is why you have generic programming in the first place. What you would rather have is a mechanism that applies formal methods to prove that a function or a class (any type with specified operations/functions) really do what they are suppose to do. This would ensure that abtractions are not just abstractions by name.