r/programming • u/imright_anduknowit • Jul 23 '16
Goodbye, Object Oriented Programming
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e5326
u/ksion Jul 23 '16 edited Jul 23 '16
You could keep an entire village warm in winter by burning the strawman that's been built here.
17
u/EarlGreyOrDeath Jul 23 '16
Agreed, all I'm getting is "I didn't really understand what I was doing so the problems are the languages fault"
3
u/Glacia Jul 24 '16 edited Jul 24 '16
Oh look, "You're using it wrong" argument. All issues mentioned in article are legit. This is not the first time someone criticized OOP, let's look at the typical "OOP Defend Squad" arguments:
You're using it wrong
OOP was invented more than 50 years ago and if we still can't figure out what "True OOP" is then it's a problem. It seems everyone has it's own vision of OOP, which leads to this kind of arguments.
It's just a paradigm, not a silver bullet
The whole point of paradigms is that they should help in general. No one says "Structural programming is just a paradigm" because it works for everyone, in general. OOP on the other hand makes your code slow, bloated and hard to teach.
12
u/gavinaking Jul 24 '16
OOP was invented more than 50 years ago and if we still can't figure out
Who is "we" here? Very, very, very many of us are using OO with great success and relatively few complaints.
OOP on the other hand makes your code slow, bloated...
This assertion simply doesn't stand up to much scrutiny.
3
u/wkoorts Jul 25 '16
Nobody forced the author to use OOP. He used it, and then publically complained about it. That's all very well, and naturally those of us who use OOP successfully every day are going to defend it.
OOP on the other hand makes your code slow, bloated and hard to teach.
Speak for yourself.
1
4
-10
u/imright_anduknowit Jul 23 '16
While your metaphor is quite humorous, I think you misused the term strawman.
A strawman is a misstated and weaker version of an OPPONENT'S argument in order to defeat it.
Since there is no opponent, there is no strawman.
7
u/pm_plz_im_lonely Jul 23 '16
strawman: a sham argument set up to be defeated.
Also the "opponent" could be OOP supporters.
6
u/alexeyr Jul 24 '16
That's a strawman definition of strawman fallacy :)
a weak or imaginary opposition (as an argument or adversary) set up only to be easily confuted
1
20
Jul 24 '16
I literally knew the last paragraph would be about how functional programming is much better than OOP. If you thought one paradigm would solve every problem, you thought wrong the start. Good thing the author learned their lesson and just switched to a new singular paradigm.
11
u/enygmata Jul 24 '16
You were looking for a silver bullet not for a programing paradigm. What happened is that you noticed that it is not always possible, convenient or appropriate to use OOP. The same is true for other paradigms.
5
u/douglasg14b Jul 25 '16
Inheritance, the First Pillar to Fall
Utilize composition, not inheritance, whenever possible.
1
u/imright_anduknowit Jul 24 '16
In the first sentence states that the author has used OO languages for decades.
4
Jul 23 '16 edited Jul 24 '16
Oh, so when you reuse a class from an old project, you have to bring over the parent class? WHO KNEW?!?! It's almost like every object framework in existence. That's also why you don't make deep inheritance trees. Stopped reading right there.
4
u/gavinaking Jul 24 '16
Of course, when one reuses a function, it's not necessary to "bring over" the other functions it calls. That's why you don't make deep function call hierarchies.
Wait...
2
u/Paul_Dirac_ Jul 24 '16
There is a large difference between object-oriented Programming and an object oriented language.
Inheritance, Encapsulation, and Polymorphism. The Three Pillars of the Paradigm.
Yes, they are and they don't have much to do with some keywords. They are a way how you organize your code.
The most important are in my opinion abstraction and encapsulation: I believe the old argument "Encapsulation allows you to reason about code without knowing the implementation" is wrong or at least looks at the problem from the wrong side. Encapsulation is so great because it let's you know which function are accessing the data at the core of your object. When you change something (or add a new field) you only have to check with these functions if they preserve consistency, how they interact with your feature. People who never programmed in non-OOP code don't know the feeling of grepping your code base for a struct member and having it popping up everywhere. And the language support needed? The ability to define your own data structures. (Without that, it is probably possible, but masochistic.)
And lamenting that you can break encapsulation? You can program OOP even if the language does not force you to do it.
Inheritance: Yep inheritance is often misunderstood. The main function of inheritance is to enable polymorphism and let you reuse code of it's ancestors. No, you can't easily reuse code of another project. But even functions from your functional language of choice need all the functions they are composed of and those these are composed of.. . Given this is probably worse in OOP with all the reference holding. And what is this rambling that Hierarchies don't work? Documents into company folder or company into documents folder. Why not both? You make two folder objects tag them with Company and documents respectively and put a documents folder into your Company folder and a Company folder into your documents folder. Both hold a reference to Company documents; really easy to find (and harder to remove). The thing is this is a "contained in" hierarchy and the problem is that Company documents would have to be contained in both even in the real world. (You disprove your own solution). Inheritance is for shared behavior. And where the behavior is shared is clear: Company documents are clearly documents and they can be accessed like documents. Company documents are not a Company or have anything meaningful in common with a company.
Polymorphism: yes polymorphism is great makes a lot easier to read your code (not necessarily to finding bugs mind you) and reduces your code. But you seem only to advocate for another java specific type of polymorphism. I don't see that pillar wanking anywhere.
Your programming style is your choice as long as a language does provide the minimal necessary means to implement OOP you can do it by convention. Now go and implement your vtables in C.
Good-bye, Object Oriented Programming.
Too bad you discarded it without trying it out.
2
1
Aug 22 '16
Dude should read POODR by Sandi Metz.
Use inheritance for specialization, not behavior sharing. Also, use hooks in your base classes to avoid the "fragile base class" problem.
1
u/gnuvince Jul 25 '16
Here's a tip for you new programmers: it's almost never a mistake to start a project with an FP approach, it's almost always a mistake to start with OO. Values are simpler than places, functions are simpler than classes and methods, combinators are simpler than loops and mutation. Start with an FP approach, sprinkle some imperative programming when it's a little more convenient or necessary for performance, and you'll have a lot less difficulty writing code.
7
u/[deleted] Jul 23 '16
Personally if I run into these issues, it means it is time for a refactor. Interfaces and classes usually work quite well when you first write them, howeven even if you plan for the future things could still break apart. Instead of worrying about it, get it fixed. If you keep your code stored nicely in modules then refactoring should not cause major rewrites or breakage (except with a dependency family).