5 ms·

>It was sold on the promise of reuse but accomplishes it at the expense of understandability and maintainability. I have never dealt with code in practice that

>It was sold on the promise of reuse but accomplishes it at the expense of understandability and maintainability. I have never dealt with code in practice that was less maintainable and understandable because of OO. Do you have a specific example?

alkonaut 10y ago
I think it's usually the case that mutability and inheritance is overused leading to deep and/or unnatural abstractions and code that is hard to reason about. Working with a hierarchy many levels deep with overrides on every level means it's very hard to reason about the code as the call stacks ride an elevator up and down the class hierarchy. Don't get me wrong - this is not an inherent drawback with OO, this is because it's applied incorrectly. Making bad abstractions or a class hierarchy 10 levels deep is bad, and it's possible that the same inexperienced developer would just make another mistake in another paradigm, leading to some other problem instead. My issue is perhaps more with the design of popular OO languages (Java, C#, C++) than with OO as a concept. A very good OO language could be made by simply encouraging best practices and removing the biggest warts (no null, immutability by default, support for sum types, encourage pure functions, discourage deep class hierarchies...). Experienced programmers can write maintainable code in any paradigm, but I think the paradigms should be judged by how well it helps average programmers write maintainable code.
- jimmaswell 10y ago
  A codebase I work on at the moment has some hierarchies go to at least 6 or 7 levels, and I haven't had a problem with it. The way it's used doesn't hurt the ability to reason about it, it's just a logical progression of categories of objects getting more specific as they branch out. This is at the same time that a lot of composition and components are used. I'd say excessively deep class hierarchy or bad abstractions are still a lot better than similarly "bad" imperative or other code, not sure about functional though.
  - alkonaut 10y ago
    > it's just a logical progression of categories of objects getting more specific as they branch out. That's the benefit of it. On a type abstraction level it's perfect to write Organism > Animal > Dog. That's the benefit of inheritance. The drawbacks are more subtle though and manifest like mad stacktraces that are very brittle to change (what happens when I change what I return from this method? Who are the downstream and upstream users? What does this stacktrace mean? When it becomes difficult to reason about is when you have all these kinds of abstractions executing at the same time - which easily happens. at Dog.CreateName at Animal.CreateName at Dog.SetNewName at Animal.ResetName at Animal.Create at Organism.Create...

alkonaut 10y ago

I think it's usually the case that mutability and inheritance is overused leading to deep and/or unnatural abstractions and code that is hard to reason about. Working with a hierarchy many levels deep with overrides on every level means it's very hard to reason about the code as the call stacks ride an elevator up and down the class hierarchy. Don't get me wrong - this is not an inherent drawback with OO, this is because it's applied incorrectly. Making bad abstractions or a class hierarchy 10 levels deep is bad, and it's possible that the same inexperienced developer would just make another mistake in another paradigm, leading to some other problem instead. My issue is perhaps more with the design of popular OO languages (Java, C#, C++) than with OO as a concept. A very good OO language could be made by simply encouraging best practices and removing the biggest warts (no null, immutability by default, support for sum types, encourage pure functions, discourage deep class hierarchies...). Experienced programmers can write maintainable code in any paradigm, but I think the paradigms should be judged by how well it helps average programmers write maintainable code.

jimmaswell 10y ago
A codebase I work on at the moment has some hierarchies go to at least 6 or 7 levels, and I haven't had a problem with it. The way it's used doesn't hurt the ability to reason about it, it's just a logical progression of categories of objects getting more specific as they branch out. This is at the same time that a lot of composition and components are used. I'd say excessively deep class hierarchy or bad abstractions are still a lot better than similarly "bad" imperative or other code, not sure about functional though.
- alkonaut 10y ago
  > it's just a logical progression of categories of objects getting more specific as they branch out. That's the benefit of it. On a type abstraction level it's perfect to write Organism > Animal > Dog. That's the benefit of inheritance. The drawbacks are more subtle though and manifest like mad stacktraces that are very brittle to change (what happens when I change what I return from this method? Who are the downstream and upstream users? What does this stacktrace mean? When it becomes difficult to reason about is when you have all these kinds of abstractions executing at the same time - which easily happens. at Dog.CreateName at Animal.CreateName at Dog.SetNewName at Animal.ResetName at Animal.Create at Organism.Create...