3 ms·

OOP seems to force you to leave the entire codebase for that class open. The member variables can be modified by the methods, which makes the variables a type

OOP seems to force you to leave the entire codebase for that class open. The member variables can be modified by the methods, which makes the variables a type of global variable, from the perspective of the method. Then over time as your code size increases, you add more methods, and they keep modifying the member variables. Now, if you’re not careful, you can have multiple vectors modifying your member variables, any which way it wants. Thus, when working with OOP, you can never seem to close out parts of the code that you had already completed and tested. Since the entire code base is opened for continual modifications.

jugg1es 6y ago
There are lots of languages that prevent this.
Fire-Dragon-DoL 6y ago
OOP doesn't even mention classes in its definition, just objects. Class oriented programming is undoubtedly a mistake, but to be fair, OOP has been so distorted that the fault cannot be in the paradigm
kaba0 6y ago
What? Class methods are responsible for upholding the class invariants. That is, it provides you a way to encapsulate internal state. Of course all your class methods should be responsible for upholding that - but if you find that there are too many methods, you perhaps need a rethinking of architecture. Perhaps adding a wrapper class over an inner class? The inner class is the only thing responsible for upholding said class invariants, but the outer one can access it in different ways, without hurting the invariants.
- blackrock 6y ago
  The problem is that it is a giant internal state. And your class can be thousands of lines long. Of which you have to keep open, as you develop it. Which forces you to keep the entire code base in your head, thus increasing the cognitive load on developing the classes. Of course, there may be ways to refactor it, but the tools given in most OOP languages, tends to be insufficient.
  - kaba0 6y ago
    It’s as big of an internal state as you make it/minimum as large as the problem domain requires. Functional programming doesn’t solve any of these problems by itself. There are cases where mutating state is better, and there are others, where it is worse fit. And the latter can just as well be expressed inside a class, like there is no requirement for mutation. I think the two should go hand-in-hand, and for different parts of a program different paradigms can be used? Maybe even add actos-based programming as a possibility, but there is nothing inherently bad with OOP imo, and it is the best way to encapsulate some logic.

jugg1es 6y ago

There are lots of languages that prevent this.

Fire-Dragon-DoL 6y ago

OOP doesn't even mention classes in its definition, just objects. Class oriented programming is undoubtedly a mistake, but to be fair, OOP has been so distorted that the fault cannot be in the paradigm

kaba0 6y ago

What? Class methods are responsible for upholding the class invariants. That is, it provides you a way to encapsulate internal state. Of course all your class methods should be responsible for upholding that - but if you find that there are too many methods, you perhaps need a rethinking of architecture. Perhaps adding a wrapper class over an inner class? The inner class is the only thing responsible for upholding said class invariants, but the outer one can access it in different ways, without hurting the invariants.

blackrock 6y ago
The problem is that it is a giant internal state. And your class can be thousands of lines long. Of which you have to keep open, as you develop it. Which forces you to keep the entire code base in your head, thus increasing the cognitive load on developing the classes. Of course, there may be ways to refactor it, but the tools given in most OOP languages, tends to be insufficient.
- kaba0 6y ago
  It’s as big of an internal state as you make it/minimum as large as the problem domain requires. Functional programming doesn’t solve any of these problems by itself. There are cases where mutating state is better, and there are others, where it is worse fit. And the latter can just as well be expressed inside a class, like there is no requirement for mutation. I think the two should go hand-in-hand, and for different parts of a program different paradigms can be used? Maybe even add actos-based programming as a possibility, but there is nothing inherently bad with OOP imo, and it is the best way to encapsulate some logic.