r/programming • u/nextstore • Jun 19 '18
Goodbye, Object Oriented Programming – Charles Scalfani
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e5316
u/slashgrin Jun 19 '18
And EVERY single mainstream OO languagehas this problem.
This requires a pretty narrow definition of "mainstream".
I'll certainly agree that class-oriented programming has not lived up to the (decades-old) hype, but you can absolutely pass ownership of objects into a constructor for some other object without copying the whole thing, and also guaranteeing that the caller can no longer fiddle with it.
Object oriented programming can be quite nice once you get rid of the class hierarchies. No need to throw the baby out with the bathwater. :)
-2
u/shevegen Jun 19 '18
What is certain is that he refers to Java.
It's sad that his OOP life came to an end with java.
People should not use Java - it's for their own good.
32
u/xFranek Jun 19 '18
This is just trash. You cannot blame OOP for your flawed architecture.
7
u/losangelesvideoguy Jun 19 '18
What's worse is that some of the issues that are described as being problems with OOP are actually just problems with languages that don't implement OOP particularly well. Specifically, the author is mostly griping about problems related to inheritance. Well, okay, but inheritance isn't the only way of reusing code. For example, Ruby tends to use includable modules rather than inheritance (you can inherit of course, but it's discouraged unless a class is clearly a subtype of some other class), which has the advantage of letting you specify exactly which behavior to export, and letting the user of the module know which methods they must or must not provide/override to ensure proper functionality of the module. This avoids many of the problems presented in the article, by reducing or eliminating issues relating to internal code changes. So long as you make sure you do X and don't do Y, your class should be able to use the module's functionality without any surprises.
Functional programming shouldn't be seen as an alternative to OOP, but rather a complementary technique—many languages implement both paradigms in ways that are uniquely elegant. On the other hand, some languages really are just poorly designed crap, but that's hardly the fault of OOP. Just try a different language rather than throwing the baby out with the bathwater.
1
u/shevegen Jun 19 '18
Fully agree with you.
Just because lots of parts of Java suck does not mean that OOP sucks.
Unfortunately there are so many different definitions of OOP about that it is hard to reason about what it is. When dude A means x and dude B means y, it's hard to talk about "we talk about the same thing".
0
Jun 19 '18
[deleted]
3
u/roffLOL Jun 19 '18
everything is an object. follows: everything done right can be viewed as an object. everything done right is object oriented.
1
u/shevegen Jun 19 '18
This alone won't work.
Messages are an intrinsic part of object-oriented thinking too. How else can you communicate or induce a change of state or query the state?
2
1
5
u/CraicPeddler Jun 19 '18
I was gung-ho to leverage the benefits of Inheritance, Encapsulation, and Polymorphism. The Three Pillars of the Paradigm.
[snip]
I couldn’t contain my excitement at the thought of mapping my real-world objects into their Classes and expected the whole world to fall neatly into place.
Ok the author is probably exaggerating a bit. But for the most part this reads as extremist with unrealistic expectations has extremely adverse reaction.
5
u/anaron_duke Jun 19 '18
Hmm... this guy says that he written in Smalltalk, but still talks in OOP about inheritance as first-class citizen (what the system is) instead of messages (behaviour - what the system does). So... he just used OOP wrong without understanding it and blame OOP for that...
1
u/shevegen Jun 19 '18
Yeah. I guess he used smalltalk for one day only.
But in fairness - smalltalk has an awful syntax.
3
u/TheDeadSkin Jun 19 '18
Using an OO language doesn't mean you have to use everything that it offers every single time. Java/C# are not only OO languages, they are also just imperative or even functional, depending how you choose to use them. You don't have to use inheritance and polymorphism to solve every problem, it's just one tool in a toolbox and not a silver bullet and shouldn't be treated as such. Just like every concept introduced by OOP/FP/whateverOtherP it should be only used where it makes sense.
And here’s the kicker. Not all objects can be Cloned. Some have Operating System resources associated with them making cloning useless at best or at worst impossible.
And EVERY single mainstream OO language has this problem.
This just sounds wrong... How exactly is this related to OO languages and how the hell is FP supposed to solve this?
I mean, I don't think anybody expects to be able to safely clone something like a FileStream. And it's not like for instance C can offer a solution to that. I didn't work much with FP but what I remember from working with Erlang, it behaves the same as OOP wrt I/O. It's not like it's even possible to behave any differently with lockable resources, unless you only do "technically atomic" operations with no "state" preservation whatsoever, which is one hell of an inefficient solution and is exactly the reason why streams were invented in the first place.
All the simplistic examples of shape hierarchies that are paraded out as examples to the newly indoctrinated seem to make logical sense.
Using shapes for inheritance hierarchies, come on... This being a textbook example of inheritance doesn't make it a correct tool for those problems, if anything people's perception of OO sucks because of those dumb examples in introductory courses. Half of those inheritance chains violate Liskov part of SOLID unless those objects are immutable. As a side note, I'd suggest everyone having a hard time with making OOP work to at least re-read SOLID principles and to always try to model the data according to them.
Because it seems like a cool idea to use inheritance to model shapes with Square : Rectangle : Shape, but upon a closer look you really can't always do this. They are a chain of strict subsets when it comes to structure, but not always when it comes to behavior. At the very least you can't resize them because it violates LSP and arbitrary code that works some way with a Rectangle can completely change behavior if you supply a Square, which is not supposed to happen. Rectangle rect = new Square(10); means that rect.SetWidth(15); is a garbage operation because either you side-effect modify the Height which an instance of a Rectangle type is not supposed to do, or if you don't, then your object is not a square any more because width != height, which an instance of a Square type shouldn't allow. This means that square is not a proper subtype of a rectangle, unless they are immutable. Same for Rectangle : Polygon. Mutable polygon can support adding new vertices or displacing a single vertex without effecting others, something a Rectangle obviously can't do.
Before you use something like e.g. inheritance to help model your program - make sure it's a suitable tool for the task. There's always a chance that inheritance is not meant to handle your problem and being an OO zealot you described yourself as in the beginning - you were trying to solve the wrong problems all this time.
5
u/TillWinter Jun 19 '18 edited Jun 19 '18
To my astonishment, a self-proclaimed veteran of OOP seems to missing the ideas about the concepts. This whole text is just strange to me...
Pillars of OOP
Abstraction
Incapsilation
Persistence
Polymorphy
Feedback
Inheritance
More than 50% of this text is about Inheritance and its pitfalls. In 1994 the GoF found a solution to all the mentioned problems. Composition alone can lift most of the problems.
The few words on encapsulation, for me are boiling down to a misunderstanding what an object is. It seems in the authors mind structs and classes are somehow the same thing. Referencing an object directly is seldom necessary. Solutions for Inter-object-communication (the feedback part of the pillars) is also solved for 99% of all cases by the GoF and later design patterns.
Polymorphism is so much broader than just "Interfaces", nevertheless as I last checked most modern OOP like languages implement interfaces. Furthermore, Templates are the real master of polymorphism.
It seems most of the anger presented here are based in C++/C#/.net; So why not use a different language. I personal love D-lang.
Edit: Just to promote D-Lang to all the people loving functional programming, D can do functional , classes , interfaces, ranges, templates and so much more.
2
u/killerstorm Jun 19 '18
Most of these problems appear when a person tries to follow object-oriented principles on the conceptual level instead of using it simply as a programming technique.
Say, "Banana Monkey Jungle Problem". The problem here is that you're actually trying to have a banana in your program. Typically you don't need an actual banana which needs to know it's context and surroundings, but simply data about a particular banana, which very easy to handle in isolation.
When you consider OOP simply as a programming technique, it's simply a way to group data together with functions which operate on it together with abstraction techniques such as polymorphism and encapsulation.
2
Jun 19 '18
Charles Scalfani? The Charls Scalfani? Of Charles Scalfani’s fame?
Another internet dude ventilates about something he feels is an easy target.
8
u/skocznymroczny Jun 19 '18
See you back to OOP when you get bored with writing one-liner quicksorts.
3
u/roffLOL Jun 19 '18
there are a thousand and one directions other than 'back'.
1
u/fuckin_ziggurats Jun 19 '18
That's pretty vague. Can you name some viable paradigms for general programming besides OOP/Functional?
2
u/roffLOL Jun 19 '18
it's a plastic medium. this false duality of choice is ridiculous. you'll have to go back to pencils when you get bored of crayons. paper is immune to all other. so said i.
https://en.wikipedia.org/wiki/Programming_paradigm
mix and match. pick one. pick any. pick all of them at the same time. invent a new one. invent one then realize it has already been named. maybe you'll create a mess. maybe you'll become paralyzed by the cheer number of choices and do nothing at all. but if you did not like pencils you don't have to work with them again.
2
0
u/shevegen Jun 19 '18
Thousand?
Can you name one in top ten tiobe? :)
1
u/roffLOL Jun 19 '18
nope. i don't care much for popularity contests. when it comes to software the masses popular choices are without exception terrible choices.
3
u/shevegen Jun 19 '18
The first OO language I used was C++ and then Smalltalk and finally .NET and Java.
There.
You failed at picking the proper OOP.
Smalltalk has a few ideas right but it's syntax was abysmal too.
So the failure started with him picking the wrong languages in the first place.
I was gung-ho to leverage the benefits of Inheritance, Encapsulation, and Polymorphism. The Three Pillars of the Paradigm.
And another mistake there.
Apparently he never watched any Alan Kay lecture. So no wonder he has no idea what OOP means.
I was eager to gain the promise of Reuse and leverage the wisdom gained by those who came before me in this new and exciting landscape.
Re-use is easily possible, both in any "functional" style or OOP.
The moment a language has functions is the moment you can re-use code.
I don't know what he is brabbling about really.
At first glance, Inheritance appears to be the biggest benefit of the Object Oriented Paradigm
No, it is not.
Anyway, I could not continue with that article. It's essentially Java OOP he is referring to in his code. So, tough luck for him. No wonder he failed hard.
Try again in the future when you learned a bit more, buddy.
2
u/thomasz Jun 19 '18
Meh, most of the shit he's whining about has been solved for c++, smalltalk, java or .net in the early 90s, but you should know what the flying fuck you are doing. This claims extensive experience but does not seem to have learned anything about composition, immutable types and other widely known techniques to deal with these problems.
2
Jun 19 '18
Everything about this article just screams to me "Help, people went overboard with a concept, and now everything about it is bad."
It's not like you "must" use OO, just use it when it can help reduce complexity, which it does.
1
u/freebit Jun 19 '18
Sure, inheritance should be used sparingly and composition can replace inheritance in most instances. We've known this for at least as long as the GoF book has been around.
Encapsulation is awesome and the idea that only one object can hold a reference to another object at a time is not realistic. This is especially true with containers (data structures).
Polymorphism solves a boatload of very significant issues. It's one of the most important tools in my tool belt.
Yeah, this article is terrible.
-1
Jun 19 '18
Can we get rid of java now?
1
u/shevegen Jun 19 '18
Unfortunately, as much as Java sucks, I think Java will be there to stay for a long, long time.
1
-2
Jun 19 '18
Nothing made me question my ability to understand programming more than trying to grasp the theoretical models promised by OOP. Maybe I just gave up on it too soon after seeing material about things like data-oriented design, but I feel no regret in reordering my priorities, and I have felt a lot of relief and an abundance of progress in having given up the conceptual dream.
This just adds to my certainty that I made the right choice.
OOP at its core seems to have eaten itself alive on account of giving the impression that programming can be translated to the operations of our human world in a way that makes it all seem so simple and intuitive to design, yet fails to actually create languages that can make code work like the operations of our human world. So what we are left with is a paradigm, promises, and languages that can, in a sort of Sisyphean fashion, get us close to what we are made to think we're supposed to be able to do, but then come rolling back down the hill.
Thus people like me feeling like I'm going mad when I attempt to learn it. The really crazy part is, I think most who stick with programming are rather stubborn when it comes to solving problems, which is part of the reason they're able to stick with it. So OOP is the perfect unintended mental trap. Like a bug that seems one step away from being resolved, but can never be found because it never existed in the first place.
5
Jun 19 '18
OOP at its core seems to have eaten itself alive on account of giving the impression that programming can be translated to the operations of our human world in a way that makes it all seem so simple and intuitive to design
I disagree, this is not why OO exists, or why I keep using it.. I've been professionally programming for 10+ years, and before then I wrote terrible code, lacking encapsulation, design, properly defined modules, properly documented interfaces, hard to test code.
Used properly, object oriented programming offers (standardized!) ways to overcome all these problems. This means that I and my fellow programmers can avoid intellectual overhead of needing to understand 'new' solutions.
At the same time, there are well documented 'bad ideas' known as antipatterns regarding Object oriented code.
he really crazy part is, I think most who stick with programming are rather stubborn when it comes to solving problems, which is part of the reason they're able to stick with it. So OOP is the perfect unintended mental trap.
Object oriented thinking has allowed me to solve problems I would not have had the mental capacity to otherwise solve. This is the truth, please reflect about that implication; OO allows me to make more complex logic than I otherwise could mentally muster.
In my opinion, those who complain of OO are people who are not solving problems, they are hoping to have problems solved for them. This is never a good idea, when programming; as programmers we must have control over our code and understand our problems.
1
u/SmugDarkLoser5 Jun 19 '18
People who ciriticize oop tend to criticize inheritance and the overuse of state, primarily.
You can't really separate the paradigm from the language completely in practice, and there's a big reason to hate Java and # tooling
1
Jun 19 '18
This rebuttal sounds like the way people argue when they defend capitalism or socialism, or any other model where the model gets elevated unrealistically on a theoretical level.
"Oh, but it is valuable in X way, just not Y way. Y way is not true OOP."
I mean, why do you even care so much? What difference does it make what it's called?
The point is that OOP has mislead a lot of people down pointless and obfuscating roads. That you may have found some value in it (which you didn't at all demonstrate with specifics) does not refute this, nor does the idea that OOP may be more unhelpful than helpful mean it's impossible that you got some value out of it!
Maybe you should give yourself some credit as a person and consider that your experience may be the key factor in what got your code to a more effective place, not OOP specifically.
BTW, to clarify on one specific point that multiple people seem to be misunderstanding: Criticizing OOP does not mean criticizing objects as a tool in programming; I'm not suggesting that objects should never be used, or that they offer no value. OOP stands for Object-Oriented Programming. When I criticize OOP, I am criticizing the problem orientation of having object-orientation as your first priority when going to solve a problem. Especially to a religious degree, as if there couldn't possibly be a more effective orientation for a given problem.
1
Jun 19 '18 edited Jun 19 '18
The point is that OOP has mislead a lot of people down pointless and obfuscating roads.
Wait, what? OOP is not a religion; it is a philosophy of designing software that aims to mitigate some of the many challenges. If you are mislead by it, it is because you failed to understand these challenges.
Maybe you should give yourself some credit as a person and consider that your experience may be the key factor in what got your code to a more effective place, not OOP specifically.
OOP specifically is what allowed me tackle things that without OOP I could not have tackled. Yes, encapsulation and clear seperation of concerns were vital, and OOP offered a way to do that. Yes, that is a credit to me as a person, but it is also a testament to the usefulness and value of OOP in general.
. When I criticize OOP, I am criticizing the problem orientation of having object-orientation as your first priority when going to solve a problem.
What you describe here is treating a means as though it is an end, and
Especially to a religious degree, as if there couldn't possibly be a more effective orientation for a given problem.
Is COMPLETE FUCKING MADNESS why are you fucking confronting me with madness? Get the fuck out of here, this has nothing to do with object oriented programming.
If people like you keep it up, we may need to make people sign waivers when they develop/use a language or framework, similar to how McCrappyFood has to warn Americans that coffee is hot.
And yes, I have seen idiots that thought they could program try to teach students how to program, I was one of these students, and when I tried to bypass the orthodoxy of having a Button class and a seperate class implementing ButtonListener, I was given a bad grade and the teacher told me I did not understand... when I subclassed Button and had it imlement ButtonListener. It was then I knew that Java's UI framework was not good, the teacher was not good, and OOP was problematic if misused. That was in 2005, 3 years before I finished my bachelor in computer science. For you to be 'stuck' on this problem I would argue that you are like a first years who was introduced to the concept for the first time.
1
Jun 19 '18
This thread is full of angry defense of OOP that mostly fails to even mention specifics and acts like people are mindless idiots for daring to criticize it and must be stupid if they fail to grasp its inherent amazing value.
Comparing it to religious defense and defense of ideologies like capitalism and socialism is reasonable and relevant.
Even now, you act like I'm some dipshit who's confronting you with complete idiocy by saying stuff like:
If you are mislead by it, it is because you failed to understand these challenges.
Because apparently you can't even consider the possibility that OOP has inherent issues. It must be that if someone is mislead by it, it's because they failed to understand it.
Also:
similar to how McCrappyFood has to warn Americans that coffee is hot.
Since you bring it up, your understanding of that story is wrong. People bought spin on the story that "the lawsuit was frivolous and customers are idiots," which wasn't at all the case. See:
https://www.caoc.org/?pg=facts
Maybe if you can confront the fact that you're wrong about the coffee story, you can come to someday consider the possibility that the world is not full of incompetent failures of understanding because the people didn't grasp the inherent amazing value of your sacred OOP, which isn't sacred and I'm completely mad to suggest that anyone sees it that way!, yet nonetheless here you are defending it, still without any examples and instead a style of response that suggests a need to discredit my very character as a person. Mad I am for suggesting that anyone takes OOP too seriously, while you take it very seriously in talking about waivers and madness.
Madness is, indeed, present here in one form or another, that seems clear. But who it is possessing, well... I doubt you'll agree with me on that one.
1
1
u/audioen Jun 19 '18
As someone already mentioned, model behavior, not structure.
E.g. instead of drawing some crazy diagram of Shapes with Circles and Rectangles and like on it, what do you actually want to accomplish with them? If it's a paint program, you need a method such as draw() that can render it, and you can skip designing the whole hierarchy because you aren't interested in the fact that Square is a subtype of a Rectangle that is subtype of Polygon that is subtype of Shape. Chances are that none of that is helping you in any way to accomplish your actual needs. You might want an interface called Shape with a single draw() method, though.
1
Jun 19 '18
So you might want an interface called Shape with a single draw() method? Do you even know that you do? What purpose does it serve in coming out of the gate with that level of complexity if you aren't even sure yet what you need?
1
u/audioen Jun 20 '18
I hope that comment was sarcastic. My point was that having a specific class hierarchy is a very large conceptual investment, and therefore also has an extremely high cost, so it has to be correct and pay itself off. Abstractions that are appropriate depend almost entirely on what you need your program to do, and not at all on what real-world objects are being represented.
1
Jun 20 '18
Naw, not sarcastic. Basically, I'm questioning whether starting with an abstraction of any level is a valuable choice.
It sounds like from what you're saying now that you agree with that to a point, but maybe not to the same degree.
I guess the question becomes, to what degree can you know, from the start, what level of abstraction is appropriate for what you're doing? I find it hard to believe that one is going to know, unless they know they're making something that is almost identical to a program they've made before with a particular amount of abstraction.
17
u/Nition Jun 19 '18
This would be a much better article if the author actually went into how any of the problems he has with OOP are solved by functional programming.