> OOP can be used to design relatively uncoupled systems.
Never go full-Object-oriented programming.
In this case I think it is valuable to make a distinction between OOP which is a style of programming, and object-oriented languages, which are just a language designed with that style in mind.
I have seen issues in codebases where developers have used OOP as style to aspire to, using it in an academic sense. They tend to try to use inheritance frequently, have deep inheritance trees, and suffer from hidden coupling through these.
On the other hand, those who use object oriented languages in a mostly functional style (side-effect free functions, effective immutability, and almost no use of inheritance) tend to be much healthier in the long term.
So it's fine to use OO languages, but never go full OO programming.
I think the poster child of going full OOP (that one can look at) is ACE/TAO [1], an implementation of CORBA. It had deep inheritance trees and abstractions piled on abstractions.
Similar to Mach and microkernels, folks ran ACE/TAO and thought CORBA was slow, when it was just the implementation that was not built for speed.
Agreed, but that wasn't what I was saying or replying to, was it?
I was arguing that method implementation tied to an instance isn't the type of thing people mean when they refer to tight coupling. Coupling is related to breakage/maintenance; when you touch this thing here, if it's tightly coupled with some other component, it will also require (sometimes unexpected) changes in that other component.
Whether one should or shouldn't go full OO is an orthogonal consideration.
Never go full-Object-oriented programming.
In this case I think it is valuable to make a distinction between OOP which is a style of programming, and object-oriented languages, which are just a language designed with that style in mind.
I have seen issues in codebases where developers have used OOP as style to aspire to, using it in an academic sense. They tend to try to use inheritance frequently, have deep inheritance trees, and suffer from hidden coupling through these.
On the other hand, those who use object oriented languages in a mostly functional style (side-effect free functions, effective immutability, and almost no use of inheritance) tend to be much healthier in the long term.
So it's fine to use OO languages, but never go full OO programming.