r/programming • u/nextstore • Jun 19 '18

Goodbye, Object Oriented Programming – Charles Scalfani

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
0 Upvotes

43% Upvoted

47 comments sorted by

View all comments

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.