51–60 of 355 posts
The reason is that a computer is fundamentally all about state and you need something to manage the that state. This is the antithesis of FP. OOP manages state somewhat nicer.
God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.
"Software Engineer, Philanthropist, Astronaut, Shark Hunter, Breaker of Chains, Lord Commander of the Snack Bin, Protector of the Repo, and Part-time Cat Dad"
Too much or just right?
"Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism."
Thanks for writing up this. I work with OOP programmers a lot and I am tired of explaining problems with OOP over and over. This article just saves me that effort.
It seems to me that my OOP is so functional that I didn't felt these issues that bad (it is true that I actively evaded them with the design) and at the same time it sounds like falling into that is typical of not so great OOP programmers. It's curious to see that OOP hate coming from someone that got a chance to work in Smalltalk.
Of course I may be dumb and what I'm asking for is ColdFusion or Business Objects or Salesforce or something.
1) Inheritance can be confusing and messy.
Yes, hence the advice: Prefer composition over inheritance. Instead of having B inherit from A, declare an interface I, and have both A and B implement I. If B wants to reuse A's functionality, it's free to do so through composition, and not through inheritance.
There are some edge cases where inheritance is vastly simpler than composition - mostly when the interface requires you to implement 20 different methods, and there's only 1 method that you really care about changing. Using inheritance here gets rid of a ton of boilerplate, but that's a conscious choice you're making. If you don't like this, just revert to using composition.
2) Encapsulations can leak if you write buggy code
Any program can break if you write buggy code. Not sure what the author's point here is. In order to encapsulate your class carefully, either accept immutable inputs, or make deep copies of them. If neither happens to work, warn users that class behavior is undefined if they misuse it. This is what every non-thread-safe class already does anyway: it warns users that if you use them in a concurrent manner, things may break.
More importantly, when dealing with internal state that's created by the class, make it private and ensure no one else can access it. This also serves to encapsulate the internal implementation and algorithm from external users.
3) Polymorphism is... not unique to OOP languages?
Yes, using interface-based polymorphism is a good idea, and covers most of what people need. How does this make the argument that we should never use OOP languages?
--------
The author brings up valid points about what to watch out for when coding in OOP. If you read other books like "Effective Java," they bring up the same points as well. But instead of acknowledging the benefits that come with OOP as well, and teaching people how to avoid these pitfalls and write code the right way, the author jumps to an extreme position that OOP languages should be abandoned entirely. Can we please avoid this type of wild overreaction, and pointless jumping from one shiny tool to the next, in a never-ending search for a silver bullet that will solve all of our problems. Because let's face facts: No such silver bullet exists.
Let's wait for a few years and we'll see plenty of articles "Goodbye functional programming". You can write good and bad stuff with OOP, you can do the same with FP. There is no one-size-fits-all porgramming style.
However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation.
The fact of the matter is that all programming languages are little more than notation systems for algorithms. The best programming language is the most accurate algorithmic notation system.
I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…
I will continue to shill for Elm[1], like I always do.
The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "the right way to do things" (aka object oriented programming). I blame languages like Java for selling certain ideas as The Right Way, and building walls that intentionally prevent you from using other techniques from different schools of thought ("everything is an object, no you can't write a function outside of a class").
I think the functional paradigm has a lot of good ideas too, but in my experience they're just as annoying if they're strictly and tastelessly applied in the same way OOP principles often are.
Don't be a "functional programmer", just take the ideas that are useful.
I tend to prefer languages and tools that adopt good ideas without promoting a single specific way of thinking.
Inheritance is overused in OOP. There are many ways to share object behaviors, inheritance only works well when you expect all objects of both classes to share all behavior except one or two things. Even then, you should investigate dependency injection before reaching for inheritance. For the example given for the Triangle Problem, the author isn't clear about exactly what behavior is being shared among the classes.…