4 ms·

I don't understand what the problem with OOP is. My OOP code has always been clean and easy for myself and other people to read and modify. When I read article

I don't understand what the problem with OOP is. My OOP code has always been clean and easy for myself and other people to read and modify. When I read articles complaining about OOP, I just can't relate at all. The idea of functional programming makes no sense to me except for writing very specific simple programs. For example, I like using some functional programming on the front end with VueJS but even there, I still allow mutations in certain parts of the code. I like being able to store state in different instances and allow it to be mutated independently of each other. I like it when related logic and state is kept close together in the code; it makes it easy to reason about different parts of the code independently. On the other hand, with functional programming, it can be difficult to figure out where state comes from because there is very little abstraction to separate different parts of the code.

kamaal 8y ago
>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that point in time you have like two problems to deal with, one is the problem itself, and second is the complexity of the language. This phenomenon has remained in the OOP world, almost forever. Things like maven have helped a little. But complexity hell has been the mainstay of OOP world for almost decades now. Sure you can write very readable OOP code. Every time I do that I see great discomfort on the face of Java programmers during code reviews. For example over all this years, I haven't met a single Java programmer who could explain why Beans are good, or even needed. So you have these religious rituals Java programmers do. They feel like their job protection scheme is at risk.
- vbsteven 8y ago
  I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exist in the Spring framework, they are there to help abstract away the complexity and flexibility of the framework so you as the application programmer can have a simple, productive programming environment, and you can still reach into the complexity (and extend it) when you need to. Beans, interface inheritance, implementation inheritance and dependency injection are the building blocks of a programming environment that allows me to be very productive, and still write maintainable, testable, extendable and configurable code.
  - letstrynvm 8y ago
    > and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have spent staring out the window. Of course who needs to reuse your own classes when you have the huge canker Boost you can drag around with you from task to task.
    - Gibbon1 8y ago
      When I was doing hardware in the 80 early 90's I came to the conclusion that the 'reusable code' fans were all missing a point. You are either writing a library,a framework, or something like that. Or you are implementing some 'business logic' The point of the former is reusability. The point of the latter is utterly not and you should not waste your company's time and money or worse let schedules slip because of it. Some further thoughts over the years. Reuseable code must have a public, well designed, sable, and documented API or it won't ever be reused. Be honest how many programs are going to reuse this code? Enough to justify all the above? Didn't think so. One of the problems with reusable code is dependencies. OOP code bases tend to have more than the ordinary number of dependencies.
      - letstrynvm 8y ago
        Yes that's basically what I found too. To practice OOP, its approach is every class should be a "library". Procedural code that doesn't have a class context is felt to be a shameful throwback to an earlier era degenerate C practices. From before some people feel they starting writing "good C++" apparently.
        Gibbon1 8y ago
        I think having done hardware first gives me a slightly different perspective. Hardware designs get reused a lot, but usually not as a drop in, it gets reworked at each reiteration. Either that are it's something you buy off the shelf in which case the design interface is absolutely stable. Think a uP chip or core. They'll fix bugs and shrink the die, but they never ever change the abstract design. You can still by 8051 cores and IC's and that design has not changed at all in 40 years. Compare with business logic. The problem is the spec and use case keeps moving. Moving way too fast to be a good library or a framework.
- gerbilly 8y ago
  One argument that I often don't see mentioned when talking about OOP code, especially the admittedly awful enterprise type, is that this style of coding is happening for a reason. I think the reason is this: you have a large sprawling codebase, consisting of tens of thousands of 'business rules' or more, and you have to find a way to allow cheap run of the mill programmers to make changes to those business rules in an approachable manner. I don't think it's fair to evaluate enterprise OOP code based on the style you would prefer when undertaking a standalone project, even a large one, when one of the very problems that this enterprise style is trying to solve is how to have hundreds of fairly green developers work on the codebase. Now, as an exercise imagine taking this social problem I've described above, and implementing it in your favourite programming style, be it lisp/scheme, functional programming, JS or whatever you prefer, and try to honestly imagine whether it would hold up any better under those conditions.
  - bigato 8y ago
    Do you mean that in order to allow green programmers to change big codebases you make the code more complex? I honestly don't understand.
    - gerbilly 8y ago
      Sorry not quite, I believe that people use OOP in enterprise settings perhaps thinking: * Encapsulation might make it safer for programmers to modify code without affecting other areas. * Inheritance will make it easier to set standards for large numbers of high turnover programmers. and that then it grows complex for various mostly social factors. The testable hypothesis in this is that if you started with another programming model, and applied the same social pressures to it, it would end up just as ugly and complex. These codebases have hordes of programmers banging away on them, with little regard for the bigger picture which makes the code ugly and inconsistent.[1] Architects then react to this and attempt to enforce standards by introducing patterns and subclasses and facades etc, which is what makes it complex. Basically, I'm saying that the main straw-man used to argue against OOP: the enterprise codebase is chosen for the wrong reasons. Put any other programming style under the same pressures and you'll end up with a similar big ball of mud. [1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons

kamaal 8y ago

>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that point in time you have like two problems to deal with, one is the problem itself, and second is the complexity of the language. This phenomenon has remained in the OOP world, almost forever. Things like maven have helped a little. But complexity hell has been the mainstay of OOP world for almost decades now. Sure you can write very readable OOP code. Every time I do that I see great discomfort on the face of Java programmers during code reviews. For example over all this years, I haven't met a single Java programmer who could explain why Beans are good, or even needed. So you have these religious rituals Java programmers do. They feel like their job protection scheme is at risk.

vbsteven 8y ago
I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exist in the Spring framework, they are there to help abstract away the complexity and flexibility of the framework so you as the application programmer can have a simple, productive programming environment, and you can still reach into the complexity (and extend it) when you need to. Beans, interface inheritance, implementation inheritance and dependency injection are the building blocks of a programming environment that allows me to be very productive, and still write maintainable, testable, extendable and configurable code.
- letstrynvm 8y ago
  > and still write maintainable, testable, extendable and configurable code. "reusable"... reusable code? That was the original point of OOP. After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have spent staring out the window. Of course who needs to reuse your own classes when you have the huge canker Boost you can drag around with you from task to task.
  - Gibbon1 8y ago
    When I was doing hardware in the 80 early 90's I came to the conclusion that the 'reusable code' fans were all missing a point. You are either writing a library,a framework, or something like that. Or you are implementing some 'business logic' The point of the former is reusability. The point of the latter is utterly not and you should not waste your company's time and money or worse let schedules slip because of it. Some further thoughts over the years. Reuseable code must have a public, well designed, sable, and documented API or it won't ever be reused. Be honest how many programs are going to reuse this code? Enough to justify all the above? Didn't think so. One of the problems with reusable code is dependencies. OOP code bases tend to have more than the ordinary number of dependencies.
    - letstrynvm 8y ago
      Yes that's basically what I found too. To practice OOP, its approach is every class should be a "library". Procedural code that doesn't have a class context is felt to be a shameful throwback to an earlier era degenerate C practices. From before some people feel they starting writing "good C++" apparently.
      - Gibbon1 8y ago
        I think having done hardware first gives me a slightly different perspective. Hardware designs get reused a lot, but usually not as a drop in, it gets reworked at each reiteration. Either that are it's something you buy off the shelf in which case the design interface is absolutely stable. Think a uP chip or core. They'll fix bugs and shrink the die, but they never ever change the abstract design. You can still by 8051 cores and IC's and that design has not changed at all in 40 years. Compare with business logic. The problem is the spec and use case keeps moving. Moving way too fast to be a good library or a framework.
gerbilly 8y ago
One argument that I often don't see mentioned when talking about OOP code, especially the admittedly awful enterprise type, is that this style of coding is happening for a reason. I think the reason is this: you have a large sprawling codebase, consisting of tens of thousands of 'business rules' or more, and you have to find a way to allow cheap run of the mill programmers to make changes to those business rules in an approachable manner. I don't think it's fair to evaluate enterprise OOP code based on the style you would prefer when undertaking a standalone project, even a large one, when one of the very problems that this enterprise style is trying to solve is how to have hundreds of fairly green developers work on the codebase. Now, as an exercise imagine taking this social problem I've described above, and implementing it in your favourite programming style, be it lisp/scheme, functional programming, JS or whatever you prefer, and try to honestly imagine whether it would hold up any better under those conditions.
- bigato 8y ago
  Do you mean that in order to allow green programmers to change big codebases you make the code more complex? I honestly don't understand.
  - gerbilly 8y ago
    Sorry not quite, I believe that people use OOP in enterprise settings perhaps thinking: * Encapsulation might make it safer for programmers to modify code without affecting other areas. * Inheritance will make it easier to set standards for large numbers of high turnover programmers. and that then it grows complex for various mostly social factors. The testable hypothesis in this is that if you started with another programming model, and applied the same social pressures to it, it would end up just as ugly and complex. These codebases have hordes of programmers banging away on them, with little regard for the bigger picture which makes the code ugly and inconsistent.[1] Architects then react to this and attempt to enforce standards by introducing patterns and subclasses and facades etc, which is what makes it complex. Basically, I'm saying that the main straw-man used to argue against OOP: the enterprise codebase is chosen for the wrong reasons. Put any other programming style under the same pressures and you'll end up with a similar big ball of mud. [1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons