10 ms·

OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou,

by dpc_pw 6y ago

OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular. OOP works on low complexity, small projects, but quickly falls apart at certain point, but then it's just head scratching and finger pointing ("this ORM is just bad, next time we will use a different one"). More experienced people figured out some way around OOP to make it more robust, so whenever OOP is criticized they just do the "oh, you just doing it wrong: insert excuse and advise here". People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

arendtio 6y ago
I think the argument is kinda cheap. I mean, there are also those people, who just understand the superficial principles of OOP and struggled to understand some OOP design and therefore don't like it. Simply saying that the people who like OOP are the ones who don't see though the folly, works the other way around too and has no real substance as an argument.
Chlorus 6y ago
> "this ORM is just bad, next time we will use a different one" ...pretty sure there are competing abstraction layers to working with DBs other programming paradigms. > OOP works on low complexity, small projects, but quickly falls apart at certain point, > More experienced people figured out some way around OOP to make it more robust, I thought it fell apart? > "oh, you just doing it wrong: insert excuse and advise here". Wait til you learn what point-free style is in Haskell! Have fun! > People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. So if you happen to like OOP, you just haven't thought it through. Thanks for the constructive comment!
- wolco 6y ago
  I think you lost the room when you mentioned Haskell. If someone has to reach point where they understand point-free style in order to form this anti-OOP opinion you won't find many takers.
- the_af 6y ago
  > "oh, you just doing it wrong: insert excuse and advise here". >> Wait til you learn what point-free style is in Haskell! Have fun! I honestly don't understand what you're trying to say here. Care to elaborate? As for ORMs: no, other styles of programming don't have this particular problem nor competing abstracting layers approaching this level of chaos. The ORM addresses a specific mismatch problem between relational databases and objects from OOP. This problem is so messily unique that it has been aptly named "The Vietnam of Computer Science": http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
  - dpc_pw 6y ago
    OOP encourages writing code in "reusable" way of having bunch of objects referencing each other, which throws out of the window the reality of data having an actual form that has to support efficient computation. This kind of works (to the point) while the data is entirely in memory, but quickly falls appart when it's a bigger data set in external storage. I am yet to see a OOP project with ORM that have not fall appart in a way I described in these twitter post: https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040
teekert 6y ago
I would really appreciate some examples of oop being "wrong" and the problem solved in a better way. I just don't see why its bad, it makes sense to me. Our lib has classes and submodules with functions. A filetype benefits from a class that contains methods to manipulate said file but other common operation are better put in a function imho. Just saying "if you are really smart you'll see that oop is bad" just sounds so... Empty.
- mywittyname 6y ago
  I personally don't like inheritance as it is implemented in Java/C++. To me it feels like terrible default way to design a language so that methods can be shared between structured data types. It's certainly useful in a lot of cases, but I don't think it is in the majority of cases. Traits feel more natural to me. Instead of needing to make a subclass of a data structure to attach a foo method to it, you can define a collection of foo methods with the same name and pick the runtime implementation based on data structures passed to the method. I understand that this six of one, half dozen of the other, but I do prefer it this way. Granted, this is not something OOP does "wrong," and you can use generics to accomplish a similar thing, so it's not that big of a deal.
  - wvenable 6y ago
    Inheritance is just traits combined interfaces. Interface is type, trait is the implementation. It just so happens that bringing the type along with the implementation is so common/useful that traits on their own aren't as common as inheritance.
- oliwarner 6y ago
  It's not empty, it's downright hypocritical. I fully accept that not everything benefits from being expressed in objects, which is why hybrid languages like Python are so excellent. But yes, even if some things don't map, keeping OOP around for things that do makes too much sense to ignore.
  - dnautics 6y ago
jariel 6y ago
Disagree entirely. OOP is 'widespread' because it is frankly a very powerful (and obvious) way to encapsulate and organize information and function by breaking down said problems into digestible units or 'mini modules' if you will, that also happens to lend well to how humans interpret the world. Polymorphism is a very powerful tool for adaption. Far from 'problems at scale' - it's the complete opposite: well designed OOP is generally the best abstraction to use at scale, to the point wherein most of the world's most comprehensive APIs are in fact OOP. Inheritance is definitely overused, and OOP is not ideal for many kinds of projects, but overall, it's successful because it's extremely useful. It's 'mid level' Engineers, those who have discovered the foibles of OOP Orthodoxy, who 'develop their own ideas for the first time' who are the most ardent critics. Those who get past that see it for what it is, just a tool, very useful in many ways, not so much in others. TypeScript has fundamentally better OO utility that Javascript, Dart was developed using OOP, Kotlin absolutely kept those ideas, etc. etc.. Obviously, maybe not the best for a lot of systems programming. It's 100% here to stay, or at least an evolution of it.
- echelon 6y ago
  I agree with you, but trying to map your problems onto tree-based OOP inheritance is absurd. Trait-based programming solves polymorphism much more elegantly as any type can adopt a behavior. These systems are going to replace the old paradigm.
  - jariel 6y ago
    Most OO paradigms include pretty strong architectures for traits/interfaces. They are definitely useful, but 'inheritance' is extremely useful in many cases wherein there is a lot of material overlap in code. It gets out of hand fast and it's not perfect, but it's just so useful at a small scale, in so many ways.
ryanisnan 6y ago
This comment reeks of frustration. Let me tell you, there is nothing "superficial" about being able to communicate effectively about code, or about how systems work. There is fundamental value in this notion.
losteric 6y ago
> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so. You seem confident in this position - can you provide some resources for others to become more familiar with that philosophy, proofs against OOP, and/or alternative approaches to architecture?
- dnautics 6y ago
  Yeah, if you've ever worked in a functional language, console'd into and looked at data in flight, and instantly identified what was wrong because data from someone else's library wasn't encapsulated behind private fields, you would never want to encapsulate anything ever again.
  - renewedrebecca 6y ago
    Even Eclipse lets you look at private data when debugging. Besides that though, you don't have to make data private- it's just common practice to do so.
    - dnautics 6y ago
      > it's just common practice to do so - key point is that is that it's common practice, and the situation you're in is debugging data emitted by someone else.
- dpc_pw 6y ago
  Please see https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 for description how OOP + ORM business code falls apart in practice, then https://dpc.pw/opportunistic-programming https://dpc.pw/opportunistic-programming for what I encourage. Then more posts there if you're still interested.
  - 6y ago
nradov 6y ago
Every programming paradigm falls apart on high complexity large projects. So OOP isn't necessarily any worse in that regard. As an industry we still haven't figured out a consistent set of best practices for such projects.
na85 6y ago
I don't see how you can manage a project of any significant complexity without objects and the way they allow you to compartmentalize your systems without relying on a bunch of global state.
- dpc_pw 6y ago
  My approach is: You decompose it into services and actors passing messages (remote vs local), withing each running an imperative shell over FP domain logic. If you care you might read more on https://dpc.pw/opportunistic-programming https://dpc.pw/opportunistic-programming and https://dpc.pw/how-i-structure-my-apps-in-rust-and-other-languages https://dpc.pw/how-i-structure-my-apps-in-rust-and-other-lan...
gnulinux 6y ago
> They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so. Can you explain these? I'd like to know why people think encapsulation and inheritance don't make sense.
- mrkeen 6y ago
 I don't know if I see eye-to-eye with grandparent but I'll give it a shot! As others have pointed out, everyone has a different definition of what the core principles of OOP are. When Alan Key coined the term "object-oriented programming", he had message passing (among other things) in mind. If you like that definition, stop reading this and go use Erlang. If you were more thinking of the various modern languages we now call OOP, read on. The "lies for small children" version is that OOP is all about modelling the real world in a natural way: apple.eat(), car.drive(), etc. Nouns are objects and verbs are methods. From my POV it's a strawman to reduce OOP to this, but I bring it up because some people like it this way and will argue for it - "It's a natural way to think about software", etc. How are nouns and verbs actually modelled in practice? You don't file.read() and file.write(), you construct a FileReader and FileWriter, and you tell them to read() and write(). The verbs ofen show up in class names (fileREADer). It's delegation of responsibility and I argue it's a good way to design software. But delegation of responsibility is not restricted to OOP. Putting aside modelling and design concerns, what are the core features of OOP languages? I like the Uncle Bob definition of Inheritance, polymorphism and encapsulation. Inheritance: Inheritance is fraught with more "lies for small children". A Lion is a type of Cat which is a type of Animal. I admit this is another strawman because using inheritance to model taxonomies like this is dumb and doesn't happen in the real world. How is inheritance used in the real world? I honestly don't see it that often. A lot of frameworks like to hijack your 'main' method and force you to use inheritance to run the thing, e.g. MyApp extends SpringApp. I keep trying to think of inheritance examples and think "no, that's just an example of using an interface". Anyway, one of the principles in the OOP body of knowledge that has emerged over time is to "favour composition over inheritance". You might get to share some behaviour and cut down some code between 2-3 classes, but on the flipside, now when you want to modify just 1 class, you have to realise you're modifying the other 2 classes as well. Elsewhere in the OOP body of knowledge is the five SOLID principles. I love SOLID. Someone familiar with SOLID might say "but we know how to safely extend classes because of the (L)iskov Substitution Principle!" But it's not an instructive way to safely use inheritance. It basically says "don't fuck up inheritance". Polymorphism: Lots of languages have polymorphism. I mainly use Java and I'm disappointed in its polymorphism story. Perhaps other OOP languages do it better? Java has interfaces/abstract-classes as well as "Generics" (first-order parametric polymorphism). First-order parametric polymorphism will let you model List<Integer> as List, but it will not let you model it as L<Integer>. Why does this matter? When you want to abstract over things that are "mappable", like Optional and Stream. Optional map(Function<? super T,? extends U> mapper); <R> Stream<R> map(Function<? super T,? extends R> mapper); I can't do this: F map(Function<? super T,? extends U> mapper); // The F stands for "Forbidden" ! I have worked on a large codebase where one of my tasks was to move from Guava Futures to Java 8 CompletableFutures. I really would have liked the ability to hide those concrete classes behind some kind of abstraction. Incidentally later on one of my colleagues said he'd like to rewrite it using Observables. At a different company one of my coworkers went the other way - he did a "hack week" project of converting a codebase from Observables to Futures. It would be better if you could just leave the business logic generic and instantiate it over an Observable or a Future as you saw fit. I don't know OO languages that let you do this. Encapsulation: I think the most promininent definition of encapsulation is you hide data inside an object and only manipulate that object using its (public) methods. Why might you want to hide data in such a way? So you can delegate responsibility to the object, because it will handle the data better than you will from outside the object. You don't need objects for that. You can do that with data and functions - unless you insist upon the apple.eat() syntax instead of eat(apple) discussed in paragraphs 2-3. NB. Putting state inside an object doesn't make it safe for concurrent modifications. But that's a whole 'nother discussion topic. In the "real world" I rarely need to use a mutable data field in an object. Fields are generally just other dependencies, e.g. database handles or other services. I think I did a reasonable job of hitting "the core principles". It's not so much that they're "bad ideas", but rather, once you strip away the large, good majority of ideas which is available outside OOP (e.g. delegation of responsibility) you're just left with the bad ideas (e.g. inheritance) or ideas which have been executed better elsewhere (polymorphism, message passing.).
mumblemumble 6y ago
I disagree, but I would agree quite strongly if it were just the first three paragraphs, with all instances of "OOP" replaced by "imperative programming." OOP really hasn't been given a fair shake. On the academic side, people figured out pretty early on that OOP doesn't mix well with an imperative programming style. It undercuts the basic idea, same as for FP. But the siren song of multi-paradigm programming is hard to resist. So the tradition of OOP that started with C++ (and ultimately displaced what the academics were working on) was basically an experiment to see if you can improve the flavor of cow pie by mixing it with apple pie. It turns out, no, not so much. You don't really make the cow pie any better, but you do make the apple pie much, much worse. Unfortunately, few people realize it's even possible to do OOP without all the BS (pun intended). Most of us have never known anything but this tradition that basically ignored everything that happened during the 1970s, rolled the universe back to the state of the art as of Simula 67, and took over the world by reassuring managers that nobody was going to try and take away their precious lowest-common-denominator imperative code. I mentioned elsewhere in the comments that Alan Kay once stated, in so many words, that to him encapsulation was about getting away from an imperative, stateful way of doing things and moving toward a much more declarative style of programming. Being able to do that was a key strength of his formulation of OOP. And it's hard to deny that he was on to something. What his lab was able to accomplish, in so little time and so few lines of code, should be enough to give anyone pause. But OOP is now strongly associated with bloated and sprawling codebases, not smaller ones. And enabling people to rise out of the imperative programming tarpit and adopt a more declarative style is now commonly cited as a key advantage of FP over OOP. Clearly, something was lost along the way.
leafboi 6y ago
>OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular. I think its more complex then this. The simplest form of programming is procedural. OOP is a level of abstraction above it in terms of understanding. I think the catharsis of grokking OOP gives it the illusion of being better.
goto11 6y ago
> OOP works on low complexity, small projects, but quickly falls apart at certain point Some very large project, like Windows and all major browser browser engines (as far as I know) are written in C++.
SCHiM 6y ago
Windows runs on millions of devices. An absolutely core pillar of Windows is COM and the most recent versions have only added to that foundation with WinRT. If anything is pure OOP it's COM. And although it has a deserved reputation for being hard to start working with, and documentation these days is sparse; it's going full-steam ahead when you boot a Windows box.
- pjmlp 6y ago
  Given that UWP is COM on steroids, there is plenty of documentation, what is hard to find is classical COM with ATL kind of stuff, but for that there are still plenty of books at a library nearby or garage sales.
valuearb 6y ago
I’m not sure I understand this. I’m working on a 100,000 line swift project and we don’t seem to have those problems. For example I just added a data caching system where a generic DataCache is used by most data types, with a few more sophisticated caches for special needs implementing the same DataCache protocols, so they can all plug in to the same places wherever needed. And a series of CacheRefresh objects that inherit base refresh functionality from a superclass, and just impose the their specific REST api calls. And everything is written as functional as possible, with limited state and parameter dependent methods. It’s working great, any model that needs caching can have a data cache, and any UI that needs to prefetch data can have a CacheRefresh object for each type of data it’s dependent on. I’ve pretty much minimized boilerplate and redundant code this way. So what am I doing wrong, or what could I be doing better?
kazinator 6y ago
> OOP is a superficial lowest common denominator of programming. That statement seems out of touch of the decades of OOP flogging that it took to get OOP support to be a staple of mainstream programming languages, so that it could be a common denominator. Just a some three decades ago, anyone using OOP terminology was instantly stereotyped as an ivory tower academic.

by dpc_pw 6y ago

arendtio 6y ago

I think the argument is kinda cheap. I mean, there are also those people, who just understand the superficial principles of OOP and struggled to understand some OOP design and therefore don't like it. Simply saying that the people who like OOP are the ones who don't see though the folly, works the other way around too and has no real substance as an argument.

Chlorus 6y ago

> "this ORM is just bad, next time we will use a different one" ...pretty sure there are competing abstraction layers to working with DBs other programming paradigms. > OOP works on low complexity, small projects, but quickly falls apart at certain point, > More experienced people figured out some way around OOP to make it more robust, I thought it fell apart? > "oh, you just doing it wrong: insert excuse and advise here". Wait til you learn what point-free style is in Haskell! Have fun! > People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. So if you happen to like OOP, you just haven't thought it through. Thanks for the constructive comment!

wolco 6y ago
I think you lost the room when you mentioned Haskell. If someone has to reach point where they understand point-free style in order to form this anti-OOP opinion you won't find many takers.
the_af 6y ago
> "oh, you just doing it wrong: insert excuse and advise here". >> Wait til you learn what point-free style is in Haskell! Have fun! I honestly don't understand what you're trying to say here. Care to elaborate? As for ORMs: no, other styles of programming don't have this particular problem nor competing abstracting layers approaching this level of chaos. The ORM addresses a specific mismatch problem between relational databases and objects from OOP. This problem is so messily unique that it has been aptly named "The Vietnam of Computer Science": http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
- dpc_pw 6y ago
  OOP encourages writing code in "reusable" way of having bunch of objects referencing each other, which throws out of the window the reality of data having an actual form that has to support efficient computation. This kind of works (to the point) while the data is entirely in memory, but quickly falls appart when it's a bigger data set in external storage. I am yet to see a OOP project with ORM that have not fall appart in a way I described in these twitter post: https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040

teekert 6y ago

I would really appreciate some examples of oop being "wrong" and the problem solved in a better way. I just don't see why its bad, it makes sense to me. Our lib has classes and submodules with functions. A filetype benefits from a class that contains methods to manipulate said file but other common operation are better put in a function imho. Just saying "if you are really smart you'll see that oop is bad" just sounds so... Empty.

mywittyname 6y ago
I personally don't like inheritance as it is implemented in Java/C++. To me it feels like terrible default way to design a language so that methods can be shared between structured data types. It's certainly useful in a lot of cases, but I don't think it is in the majority of cases. Traits feel more natural to me. Instead of needing to make a subclass of a data structure to attach a foo method to it, you can define a collection of foo methods with the same name and pick the runtime implementation based on data structures passed to the method. I understand that this six of one, half dozen of the other, but I do prefer it this way. Granted, this is not something OOP does "wrong," and you can use generics to accomplish a similar thing, so it's not that big of a deal.
- wvenable 6y ago
  Inheritance is just traits combined interfaces. Interface is type, trait is the implementation. It just so happens that bringing the type along with the implementation is so common/useful that traits on their own aren't as common as inheritance.
oliwarner 6y ago
It's not empty, it's downright hypocritical. I fully accept that not everything benefits from being expressed in objects, which is why hybrid languages like Python are so excellent. But yes, even if some things don't map, keeping OOP around for things that do makes too much sense to ignore.
- dnautics 6y ago

jariel 6y ago

Disagree entirely. OOP is 'widespread' because it is frankly a very powerful (and obvious) way to encapsulate and organize information and function by breaking down said problems into digestible units or 'mini modules' if you will, that also happens to lend well to how humans interpret the world. Polymorphism is a very powerful tool for adaption. Far from 'problems at scale' - it's the complete opposite: well designed OOP is generally the best abstraction to use at scale, to the point wherein most of the world's most comprehensive APIs are in fact OOP. Inheritance is definitely overused, and OOP is not ideal for many kinds of projects, but overall, it's successful because it's extremely useful. It's 'mid level' Engineers, those who have discovered the foibles of OOP Orthodoxy, who 'develop their own ideas for the first time' who are the most ardent critics. Those who get past that see it for what it is, just a tool, very useful in many ways, not so much in others. TypeScript has fundamentally better OO utility that Javascript, Dart was developed using OOP, Kotlin absolutely kept those ideas, etc. etc.. Obviously, maybe not the best for a lot of systems programming. It's 100% here to stay, or at least an evolution of it.

echelon 6y ago
I agree with you, but trying to map your problems onto tree-based OOP inheritance is absurd. Trait-based programming solves polymorphism much more elegantly as any type can adopt a behavior. These systems are going to replace the old paradigm.
- jariel 6y ago
  Most OO paradigms include pretty strong architectures for traits/interfaces. They are definitely useful, but 'inheritance' is extremely useful in many cases wherein there is a lot of material overlap in code. It gets out of hand fast and it's not perfect, but it's just so useful at a small scale, in so many ways.

ryanisnan 6y ago

This comment reeks of frustration. Let me tell you, there is nothing "superficial" about being able to communicate effectively about code, or about how systems work. There is fundamental value in this notion.

losteric 6y ago

> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so. You seem confident in this position - can you provide some resources for others to become more familiar with that philosophy, proofs against OOP, and/or alternative approaches to architecture?

dnautics 6y ago
Yeah, if you've ever worked in a functional language, console'd into and looked at data in flight, and instantly identified what was wrong because data from someone else's library wasn't encapsulated behind private fields, you would never want to encapsulate anything ever again.
- renewedrebecca 6y ago
  Even Eclipse lets you look at private data when debugging. Besides that though, you don't have to make data private- it's just common practice to do so.
  - dnautics 6y ago
    > it's just common practice to do so - key point is that is that it's common practice, and the situation you're in is debugging data emitted by someone else.
dpc_pw 6y ago
Please see https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 for description how OOP + ORM business code falls apart in practice, then https://dpc.pw/opportunistic-programming https://dpc.pw/opportunistic-programming for what I encourage. Then more posts there if you're still interested.
- 6y ago

nradov 6y ago

Every programming paradigm falls apart on high complexity large projects. So OOP isn't necessarily any worse in that regard. As an industry we still haven't figured out a consistent set of best practices for such projects.

na85 6y ago

I don't see how you can manage a project of any significant complexity without objects and the way they allow you to compartmentalize your systems without relying on a bunch of global state.

dpc_pw 6y ago
My approach is: You decompose it into services and actors passing messages (remote vs local), withing each running an imperative shell over FP domain logic. If you care you might read more on https://dpc.pw/opportunistic-programming https://dpc.pw/opportunistic-programming and https://dpc.pw/how-i-structure-my-apps-in-rust-and-other-languages https://dpc.pw/how-i-structure-my-apps-in-rust-and-other-lan...

gnulinux 6y ago

> They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so. Can you explain these? I'd like to know why people think encapsulation and inheritance don't make sense.

mrkeen 6y ago
I don't know if I see eye-to-eye with grandparent but I'll give it a shot! As others have pointed out, everyone has a different definition of what the core principles of OOP are. When Alan Key coined the term "object-oriented programming", he had message passing (among other things) in mind. If you like that definition, stop reading this and go use Erlang. If you were more thinking of the various modern languages we now call OOP, read on. The "lies for small children" version is that OOP is all about modelling the real world in a natural way: apple.eat(), car.drive(), etc. Nouns are objects and verbs are methods. From my POV it's a strawman to reduce OOP to this, but I bring it up because some people like it this way and will argue for it - "It's a natural way to think about software", etc. How are nouns and verbs actually modelled in practice? You don't file.read() and file.write(), you construct a FileReader and FileWriter, and you tell them to read() and write(). The verbs ofen show up in class names (fileREADer). It's delegation of responsibility and I argue it's a good way to design software. But delegation of responsibility is not restricted to OOP. Putting aside modelling and design concerns, what are the core features of OOP languages? I like the Uncle Bob definition of Inheritance, polymorphism and encapsulation. Inheritance: Inheritance is fraught with more "lies for small children". A Lion is a type of Cat which is a type of Animal. I admit this is another strawman because using inheritance to model taxonomies like this is dumb and doesn't happen in the real world. How is inheritance used in the real world? I honestly don't see it that often. A lot of frameworks like to hijack your 'main' method and force you to use inheritance to run the thing, e.g. MyApp extends SpringApp. I keep trying to think of inheritance examples and think "no, that's just an example of using an interface". Anyway, one of the principles in the OOP body of knowledge that has emerged over time is to "favour composition over inheritance". You might get to share some behaviour and cut down some code between 2-3 classes, but on the flipside, now when you want to modify just 1 class, you have to realise you're modifying the other 2 classes as well. Elsewhere in the OOP body of knowledge is the five SOLID principles. I love SOLID. Someone familiar with SOLID might say "but we know how to safely extend classes because of the (L)iskov Substitution Principle!" But it's not an instructive way to safely use inheritance. It basically says "don't fuck up inheritance". Polymorphism: Lots of languages have polymorphism. I mainly use Java and I'm disappointed in its polymorphism story. Perhaps other OOP languages do it better? Java has interfaces/abstract-classes as well as "Generics" (first-order parametric polymorphism). First-order parametric polymorphism will let you model List<Integer> as List, but it will not let you model it as L<Integer>. Why does this matter? When you want to abstract over things that are "mappable", like Optional and Stream. Optional map(Function<? super T,? extends U> mapper); <R> Stream<R> map(Function<? super T,? extends R> mapper); I can't do this: F map(Function<? super T,? extends U> mapper); // The F stands for "Forbidden" ! I have worked on a large codebase where one of my tasks was to move from Guava Futures to Java 8 CompletableFutures. I really would have liked the ability to hide those concrete classes behind some kind of abstraction. Incidentally later on one of my colleagues said he'd like to rewrite it using Observables. At a different company one of my coworkers went the other way - he did a "hack week" project of converting a codebase from Observables to Futures. It would be better if you could just leave the business logic generic and instantiate it over an Observable or a Future as you saw fit. I don't know OO languages that let you do this. Encapsulation: I think the most promininent definition of encapsulation is you hide data inside an object and only manipulate that object using its (public) methods. Why might you want to hide data in such a way? So you can delegate responsibility to the object, because it will handle the data better than you will from outside the object. You don't need objects for that. You can do that with data and functions - unless you insist upon the apple.eat() syntax instead of eat(apple) discussed in paragraphs 2-3. NB. Putting state inside an object doesn't make it safe for concurrent modifications. But that's a whole 'nother discussion topic. In the "real world" I rarely need to use a mutable data field in an object. Fields are generally just other dependencies, e.g. database handles or other services. I think I did a reasonable job of hitting "the core principles". It's not so much that they're "bad ideas", but rather, once you strip away the large, good majority of ideas which is available outside OOP (e.g. delegation of responsibility) you're just left with the bad ideas (e.g. inheritance) or ideas which have been executed better elsewhere (polymorphism, message passing.).

mumblemumble 6y ago

I disagree, but I would agree quite strongly if it were just the first three paragraphs, with all instances of "OOP" replaced by "imperative programming." OOP really hasn't been given a fair shake. On the academic side, people figured out pretty early on that OOP doesn't mix well with an imperative programming style. It undercuts the basic idea, same as for FP. But the siren song of multi-paradigm programming is hard to resist. So the tradition of OOP that started with C++ (and ultimately displaced what the academics were working on) was basically an experiment to see if you can improve the flavor of cow pie by mixing it with apple pie. It turns out, no, not so much. You don't really make the cow pie any better, but you do make the apple pie much, much worse. Unfortunately, few people realize it's even possible to do OOP without all the BS (pun intended). Most of us have never known anything but this tradition that basically ignored everything that happened during the 1970s, rolled the universe back to the state of the art as of Simula 67, and took over the world by reassuring managers that nobody was going to try and take away their precious lowest-common-denominator imperative code. I mentioned elsewhere in the comments that Alan Kay once stated, in so many words, that to him encapsulation was about getting away from an imperative, stateful way of doing things and moving toward a much more declarative style of programming. Being able to do that was a key strength of his formulation of OOP. And it's hard to deny that he was on to something. What his lab was able to accomplish, in so little time and so few lines of code, should be enough to give anyone pause. But OOP is now strongly associated with bloated and sprawling codebases, not smaller ones. And enabling people to rise out of the imperative programming tarpit and adopt a more declarative style is now commonly cited as a key advantage of FP over OOP. Clearly, something was lost along the way.

leafboi 6y ago

>OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular. I think its more complex then this. The simplest form of programming is procedural. OOP is a level of abstraction above it in terms of understanding. I think the catharsis of grokking OOP gives it the illusion of being better.

goto11 6y ago

> OOP works on low complexity, small projects, but quickly falls apart at certain point Some very large project, like Windows and all major browser browser engines (as far as I know) are written in C++.

SCHiM 6y ago

Windows runs on millions of devices. An absolutely core pillar of Windows is COM and the most recent versions have only added to that foundation with WinRT. If anything is pure OOP it's COM. And although it has a deserved reputation for being hard to start working with, and documentation these days is sparse; it's going full-steam ahead when you boot a Windows box.

pjmlp 6y ago
Given that UWP is COM on steroids, there is plenty of documentation, what is hard to find is classical COM with ATL kind of stuff, but for that there are still plenty of books at a library nearby or garage sales.

valuearb 6y ago

I’m not sure I understand this. I’m working on a 100,000 line swift project and we don’t seem to have those problems. For example I just added a data caching system where a generic DataCache is used by most data types, with a few more sophisticated caches for special needs implementing the same DataCache protocols, so they can all plug in to the same places wherever needed. And a series of CacheRefresh objects that inherit base refresh functionality from a superclass, and just impose the their specific REST api calls. And everything is written as functional as possible, with limited state and parameter dependent methods. It’s working great, any model that needs caching can have a data cache, and any UI that needs to prefetch data can have a CacheRefresh object for each type of data it’s dependent on. I’ve pretty much minimized boilerplate and redundant code this way. So what am I doing wrong, or what could I be doing better?

kazinator 6y ago

> OOP is a superficial lowest common denominator of programming. That statement seems out of touch of the decades of OOP flogging that it took to get OOP support to be a staple of mainstream programming languages, so that it could be a common denominator. Just a some three decades ago, anyone using OOP terminology was instantly stereotyped as an ivory tower academic.