9 ms·

The faster you unlearn OOP, the better for you and your software

39 points by signa11 5y ago

al2o3cr 5y ago
I don't think there's a silver bullet, so I'm going to just describe how it tends to work in my code nowadays. "Having just explained how everything in OOP is _definitely_ wrong, I will now offer my personal philosophy as a replacement"
- apetrovic 5y ago
  "OOP is bad because objects holds references to other objects. Let's speed that up by assigning every record unique id so other records can query some table by that id and reference it"
threatofrain 5y ago
It's not worth rehashing this debate unless someone brings something new to the table, but this is just a short blog post.
jayd16 5y ago
Hammers are great. Don't use hammers on screws. Don't forget about hammers either. Just learn more tools and techniques.
vnorilo 5y ago
I recognize the object graph spaghetti the author is talking about and do find that distasteful. However, as everyone knows, even a functionally inclined guy like me, there are great OOP codebases all around us. I wonder if the problem is how OOP modeling is taught. It's easy to project all sorts of everyday instincts onto an object graph that have nothing to do with software design. I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo".
- bobmaxup 5y ago
  > I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo". Why? How should it begin?
  - HellDunkel 5y ago
    Good example of completely igoring the „data“ part. What are the inputs and outputs? In some cases it would make better sense to differentiate the train vehicle by a type enum, where as in other situations it might make sense to derive from a general „vehicle“. why, when and how are the important things to think about and this should be taught.
  - vnorilo 5y ago
    I skimmed a lot of low quality C++ intro books to try and find some good ones for beginning students. Slim pickings. I recognized this pattern of solving some ridicilous non-problem to exhibit inheritance very early on. The message readers get from that is that inheritance is OOP, and the main thing is to first think what could inherit from what. This is not a fault in OOP itself, just a very bad approach to teaching it. In my teaching I always wanted to start from a problem that required single dispatch runtime polymorphism and introduced pure abstract classes (interface and implementations) as the means of accomplishing that. I felt that if there was just one C++ class programming pattern they ought to pick up, that was it.
    - Gibbon1 5y ago
      I feel like generics without type erasure actually solves the problem that inheritance was supposed to solve without creating a swamp of dependencies.
- tored 5y ago
  Yes, I think it would be better to start with composition with a few classes that you inject into your implementation. Next step is to replace those few classes with interfaces and test with multiple implementations of these interfaces. Class done. Edit: another important part is to separate your classes into two different types so you don’t end up as described in the article. One type of class is data only, like old style struct. The other type of class is a repository type, class for working with data classes. Thus you never ask a data class for more data, you ask a repository class for that. That eliminates the problem that the article describes as complex relations between data classes. Benefit of this is that you can create data classes from different sources, thus it becomes easier to gradually rewrite your storage as long as the data classes stays the same. Edit 2: the author of the article seem to describe something what I wrote, a datastore that exposes plain data objects.
meesterdude 5y ago
OOP doesn't work for the author, while I wouldn't be a developer without OOP. Does not make them wrong, or me right. Where the author fails is in recognizing these different approaches can coexist in the field of software engineering; there is no ONE way to build software, and no way is without it's tradeoffs. OOP is how I think. There is no reasoned argument one could make to undo that. No amount of rightness will change my nature, which leaves this as a boastful display of ones ego and not any meaningful movement in computer science or engineering. Instead: I would love for the author, if they truly know better, to take those specific situations they highlighted and detail ways those could be improved or done differently. Because they are hard problems, and it would be meaningful & educational to explore refactors to improve.
- didibus 5y ago
  Question to you, did you learn programming through OOP? Cause when you say "OOP is how I think. There is no reasoned argument one could make to undo that", it isn't clear what is the chicken and what is the egg. Do you think naturally in a way where OOP is compatible with your thinking process, or did you learn to think that way?
  - danaris 5y ago
    Can't speak for meesterdude, but... I learned programming first with BASIC, then with C, without any object-oriented trappings. One of my earlier computer science classes was a survey of programming languages of various types, including procedural languages, functional languages and Smalltalk, the grandaddy of object-oriented languages. Programming has always felt most natural to me in an object-oriented paradigm. My brain categorizes things in the world into object hierarchies very intuitively. While I have no scientific evidence that this is the case, I suspect that it is one of the programming modalities that our brains are best-adapted to naturally—or at least, are likely to be, as everyone's brain is different.
    - menotyou 5y ago
      I agree to your point in a way. But for me it is just the opposite, OOP is as counter-intuitive as it can be. My mental model of the world is not categorizing things in the world into object hierarchies. And I always found it absurdly complicated to model anything hierarchies and objects which have attributes and methods. For me OOP code is just obfuscated way of getting things done. So my take on the OOP debate is that is depended on how you brain works whether you'd consider OOP as being awesome or awful. I for myself hate OOP. I find non OOP Program always more easy to understand, having a better organized code base, and are more easy to handle complex requirements because you can modularize you functions more easily, and by far less boilerplate code.
samsquire 5y ago
The author misunderstands schizophrenia and I don't think they understand what OOP brings to the table. Using objects in your design makes your code easier to understand. Using objects does not prevent you from using data oriented architecture. OOP is better than having lots of global functions that operate on data. It organises your data and code together. It makes APIs easier to use. Call a function, get a response, call functions on response object. It layers your API ordering and makes them inherently understandable. At least good OOP does. Nowhere in this article prevents you from using objects. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA
- dvfjsdhgfv 5y ago
  > OOP is better than having lots of global functions that operate on data. "Lots of global functions" is not the only alternative though.
  - Gibbon1 5y ago
    If your solution is a data oriented pipeline, OOP I think just gets in the way.
- bluefirebrand 5y ago
  > Using objects in your design makes your code easier to understand To a point. Past a certain tipping point I find OOP programs become extremely over-abstracted and bloated with way-too-much boilerplate, to the point where it becomes very difficult to work on.
Tabular-Iceberg 5y ago
> Object-oriented programming is an exceptionally bad idea which could only have originated in California. What about Norway?
- tored 5y ago
  NO
simonhamp 5y ago
I use OOP every single day. I don't have the issues the author expresses. Am I doing it wrong? The answer is no. My yardstick is: when it becomes challenging, be pragmatic about it. We write code. We're not etching letters into concrete here. This stuff can change. Make a decision, move forward. When you know more, make a change. Every system can trigger indecision paralysis - OOP is no better or worse than any other at that, just different.
deleted 5y ago
[deleted]
tengbretson 5y ago
I'm not going to challenge any of the criticisms of OOP, because most of them are valid. That being said, nearly every codebase I've seen* where the maintainers say that they're "not doing OOP" it's really just been a coded way of saying that they don't want any forethought in how they model data structures and their relationships, and to not think through their abstractions. In all of these cases yeah, give me oop. Warts and all. *This does not include hobby projects by FP nerds, but that's not what I get to deal with at a day job now is it?
neatze 5y ago
Seems like author makes argument of composition over inheritance in some form, without specific use case and most importantly possible evolution of given use case, arguing about such topic to me is useless, to very large extent.
Toutouxc 5y ago
Nope, that article doesn't offer any interesting points. Also it's sad how often people think they're arguing against OOP while they're actually arguing against Java. I like Ruby and Ruby's kind of OOP. The kind without ContextFactoryFactories.
ljm 5y ago
I contend that 'unlearning OOP' might well set you up for making the same kind of mistakes that a thoughtful OOP approach would avoid. But when people criticise OOP, I tend to believe the criticism is really about a thoughtless application of design patterns. Just using them because they're patterns, and putting those front and centre, rather than considering what's appropriate within the problem space.
deleted 5y ago
[deleted]
dragonwriter 5y ago
Unlearning OOP is probably counterproductive, and a lot less important than learning non-OOP paradigms. You can make better tool choices (and paradigms aren’t mutually exclusive, so thr choice can be a mix or hybrid) when you understand more tools, not fewer. And this applies, in software engineering, not only to programming paradigms but also to analysis and design processes and strategies (and while described as being about “OOP”, this is largely about analysis/design process.)
tored 5y ago
I think that one of the underlying problems here is the combination of OOP and an ORM, that is usually what creates the mess to begin with. OOP + ORM is very powerful super weapon, but an ORM will slowly infect every part of your code base and it is really hard to refactor when it has. Typically the most common ORM class is an active record (or similar) thingie that encapsulates multiple different steps into one, eg, * connection handling * transactions handling * querying data * writing data * hydration of data * relationship handling * schema awareness * data validation * injection prevention * cache creation & invalidation (data, query, statement caches etc) * and more Basically it is a gigantic GOD class. Of course your code base will suffer. I agree with the article authors solution to use some sort of DataStore that only talks plain objects, however I'm not sure I agree with the statement that it is OOP to be blamed or needs to be unlearned. Author mentions Java, Java community's take on OOP, with de facto standard of using Spring + Hibernate is more likely to be the underlying problem. Just like how ORM's infects everything, Java's take on OOP has unfortunately infected other communities too.

39 points by signa11 5y ago

I don't think there's a silver bullet, so I'm going to just describe how it tends to work in my code nowadays. "Having just explained how everything in OOP is _definitely_ wrong, I will now offer my personal philosophy as a replacement"

apetrovic 5y ago
"OOP is bad because objects holds references to other objects. Let's speed that up by assigning every record unique id so other records can query some table by that id and reference it"

threatofrain 5y ago

It's not worth rehashing this debate unless someone brings something new to the table, but this is just a short blog post.

jayd16 5y ago

Hammers are great. Don't use hammers on screws. Don't forget about hammers either. Just learn more tools and techniques.

vnorilo 5y ago

I recognize the object graph spaghetti the author is talking about and do find that distasteful. However, as everyone knows, even a functionally inclined guy like me, there are great OOP codebases all around us. I wonder if the problem is how OOP modeling is taught. It's easy to project all sorts of everyday instincts onto an object graph that have nothing to do with software design. I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo".

bobmaxup 5y ago
> I certainly feel that there is something deeply and irredeemably wrong with every learning journey that begins with class Train overriding Vehicle::Move to print "choo choo". Why? How should it begin?
- HellDunkel 5y ago
  Good example of completely igoring the „data“ part. What are the inputs and outputs? In some cases it would make better sense to differentiate the train vehicle by a type enum, where as in other situations it might make sense to derive from a general „vehicle“. why, when and how are the important things to think about and this should be taught.
- vnorilo 5y ago
  I skimmed a lot of low quality C++ intro books to try and find some good ones for beginning students. Slim pickings. I recognized this pattern of solving some ridicilous non-problem to exhibit inheritance very early on. The message readers get from that is that inheritance is OOP, and the main thing is to first think what could inherit from what. This is not a fault in OOP itself, just a very bad approach to teaching it. In my teaching I always wanted to start from a problem that required single dispatch runtime polymorphism and introduced pure abstract classes (interface and implementations) as the means of accomplishing that. I felt that if there was just one C++ class programming pattern they ought to pick up, that was it.
  - Gibbon1 5y ago
    I feel like generics without type erasure actually solves the problem that inheritance was supposed to solve without creating a swamp of dependencies.
tored 5y ago
Yes, I think it would be better to start with composition with a few classes that you inject into your implementation. Next step is to replace those few classes with interfaces and test with multiple implementations of these interfaces. Class done. Edit: another important part is to separate your classes into two different types so you don’t end up as described in the article. One type of class is data only, like old style struct. The other type of class is a repository type, class for working with data classes. Thus you never ask a data class for more data, you ask a repository class for that. That eliminates the problem that the article describes as complex relations between data classes. Benefit of this is that you can create data classes from different sources, thus it becomes easier to gradually rewrite your storage as long as the data classes stays the same. Edit 2: the author of the article seem to describe something what I wrote, a datastore that exposes plain data objects.

meesterdude 5y ago

OOP doesn't work for the author, while I wouldn't be a developer without OOP. Does not make them wrong, or me right. Where the author fails is in recognizing these different approaches can coexist in the field of software engineering; there is no ONE way to build software, and no way is without it's tradeoffs. OOP is how I think. There is no reasoned argument one could make to undo that. No amount of rightness will change my nature, which leaves this as a boastful display of ones ego and not any meaningful movement in computer science or engineering. Instead: I would love for the author, if they truly know better, to take those specific situations they highlighted and detail ways those could be improved or done differently. Because they are hard problems, and it would be meaningful & educational to explore refactors to improve.

didibus 5y ago
Question to you, did you learn programming through OOP? Cause when you say "OOP is how I think. There is no reasoned argument one could make to undo that", it isn't clear what is the chicken and what is the egg. Do you think naturally in a way where OOP is compatible with your thinking process, or did you learn to think that way?
- danaris 5y ago
  Can't speak for meesterdude, but... I learned programming first with BASIC, then with C, without any object-oriented trappings. One of my earlier computer science classes was a survey of programming languages of various types, including procedural languages, functional languages and Smalltalk, the grandaddy of object-oriented languages. Programming has always felt most natural to me in an object-oriented paradigm. My brain categorizes things in the world into object hierarchies very intuitively. While I have no scientific evidence that this is the case, I suspect that it is one of the programming modalities that our brains are best-adapted to naturally—or at least, are likely to be, as everyone's brain is different.
  - menotyou 5y ago
    I agree to your point in a way. But for me it is just the opposite, OOP is as counter-intuitive as it can be. My mental model of the world is not categorizing things in the world into object hierarchies. And I always found it absurdly complicated to model anything hierarchies and objects which have attributes and methods. For me OOP code is just obfuscated way of getting things done. So my take on the OOP debate is that is depended on how you brain works whether you'd consider OOP as being awesome or awful. I for myself hate OOP. I find non OOP Program always more easy to understand, having a better organized code base, and are more easy to handle complex requirements because you can modularize you functions more easily, and by far less boilerplate code.

samsquire 5y ago

The author misunderstands schizophrenia and I don't think they understand what OOP brings to the table. Using objects in your design makes your code easier to understand. Using objects does not prevent you from using data oriented architecture. OOP is better than having lots of global functions that operate on data. It organises your data and code together. It makes APIs easier to use. Call a function, get a response, call functions on response object. It layers your API ordering and makes them inherently understandable. At least good OOP does. Nowhere in this article prevents you from using objects. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA

dvfjsdhgfv 5y ago
> OOP is better than having lots of global functions that operate on data. "Lots of global functions" is not the only alternative though.
- Gibbon1 5y ago
  If your solution is a data oriented pipeline, OOP I think just gets in the way.
bluefirebrand 5y ago
> Using objects in your design makes your code easier to understand To a point. Past a certain tipping point I find OOP programs become extremely over-abstracted and bloated with way-too-much boilerplate, to the point where it becomes very difficult to work on.

Tabular-Iceberg 5y ago

> Object-oriented programming is an exceptionally bad idea which could only have originated in California. What about Norway?

tored 5y ago
NO

simonhamp 5y ago

I use OOP every single day. I don't have the issues the author expresses. Am I doing it wrong? The answer is no. My yardstick is: when it becomes challenging, be pragmatic about it. We write code. We're not etching letters into concrete here. This stuff can change. Make a decision, move forward. When you know more, make a change. Every system can trigger indecision paralysis - OOP is no better or worse than any other at that, just different.

deleted 5y ago

[deleted]

tengbretson 5y ago

I'm not going to challenge any of the criticisms of OOP, because most of them are valid. That being said, nearly every codebase I've seen* where the maintainers say that they're "not doing OOP" it's really just been a coded way of saying that they don't want any forethought in how they model data structures and their relationships, and to not think through their abstractions. In all of these cases yeah, give me oop. Warts and all. *This does not include hobby projects by FP nerds, but that's not what I get to deal with at a day job now is it?

neatze 5y ago

Seems like author makes argument of composition over inheritance in some form, without specific use case and most importantly possible evolution of given use case, arguing about such topic to me is useless, to very large extent.

Toutouxc 5y ago

Nope, that article doesn't offer any interesting points. Also it's sad how often people think they're arguing against OOP while they're actually arguing against Java. I like Ruby and Ruby's kind of OOP. The kind without ContextFactoryFactories.

ljm 5y ago

I contend that 'unlearning OOP' might well set you up for making the same kind of mistakes that a thoughtful OOP approach would avoid. But when people criticise OOP, I tend to believe the criticism is really about a thoughtless application of design patterns. Just using them because they're patterns, and putting those front and centre, rather than considering what's appropriate within the problem space.

deleted 5y ago

[deleted]

dragonwriter 5y ago

Unlearning OOP is probably counterproductive, and a lot less important than learning non-OOP paradigms. You can make better tool choices (and paradigms aren’t mutually exclusive, so thr choice can be a mix or hybrid) when you understand more tools, not fewer. And this applies, in software engineering, not only to programming paradigms but also to analysis and design processes and strategies (and while described as being about “OOP”, this is largely about analysis/design process.)

tored 5y ago

I think that one of the underlying problems here is the combination of OOP and an ORM, that is usually what creates the mess to begin with. OOP + ORM is very powerful super weapon, but an ORM will slowly infect every part of your code base and it is really hard to refactor when it has. Typically the most common ORM class is an active record (or similar) thingie that encapsulates multiple different steps into one, eg, * connection handling * transactions handling * querying data * writing data * hydration of data * relationship handling * schema awareness * data validation * injection prevention * cache creation & invalidation (data, query, statement caches etc) * and more Basically it is a gigantic GOD class. Of course your code base will suffer. I agree with the article authors solution to use some sort of DataStore that only talks plain objects, however I'm not sure I agree with the statement that it is OOP to be blamed or needs to be unlearned. Author mentions Java, Java community's take on OOP, with de facto standard of using Spring + Hibernate is more likely to be the underlying problem. Just like how ORM's infects everything, Java's take on OOP has unfortunately infected other communities too.