4 ms·
Many of these points highlight OOP of 15 years ago, not OOP as practiced by many today. The others are highly contentious. As for UIs, React is OOP. It borrows
by spronkey 8y ago
Many of these points highlight OOP of 15 years ago, not OOP as practiced by many today. The others are highly contentious.
As for UIs, React is OOP. It borrows many ideas from FRP, but at its core are objects that have behaviour and state (components), and a system to orchestrate them. It might not be OO from 1990s Java, but it's definitely OO.
As for the rest, well:
* The concept of "values" form the basis for several important OOP design patterns - such as Value Objects and DTOs.
* Anything but very lightweight inheritance hasn't been in favour for many years, and most good OO developers favour composition.
* Writing the simplest version of code for today is a key tenet of TDD as practiced by several OOP leaders such as Bob Martin.
* GOTO is a permanent and nonreturnable change in program flow with little boundaries. Message passing is entirely different, very much bounded, and executed within control flows.
* Poorly designed tests are coupled heavily to code. Good tests are not. Test fakes can actually simplify debugging by removing and isolating large portions of the system.
* Most OO languages have a switch case that's perfectly acceptable to use. Many real-world applications that have never-ending spec changes (compilers work to a pretty limited and well-defined spec) benefit from using polymorphism to allow easier extensibility.
As a paradigm OOP encompasses a particularly wide spectrum, so while you can of course practice the worst OO has to offer in the form of deep inheritance hierarchies and overuse of design patterns "because we'll need them later", none of this is endemic to OO. In fact there's quite a happy medium combining OO with FP concepts (such as React) - or using OO at the boundaries to help assemble and mutate data before it gets passed to a core of pure functions.
As with everything, it's all about picking the right tool for the job, and getting the most out of the tools you are using. Steak knives and bread knives look almost exactly the same, but one is a lot better for tearing through meat.
- pacala 7y agoExactly right. OOP is a historical failure. We can't be using OOP to describe [immutable] value oriented programming [roughly functional programming] and FRP, unless we devoid OOP of most of its historical meaning. Historical OOP orthodoxy took great lengths to contrast objects to values. For example, support for values in OOP mainstream languages has been tepid. With Java still failing to fully support value objects at the language level, project Lombok notwithstanding. With Python adding dataclasses support as late as 2017. There is a reason for decades of dragging the foot: OOP orthodoxy shuns values in favor of objects, defined as "identity, [...] state (data) and behavior (code)" [0]. Insisting on "objects" as the only right way to structure programming _is_ the historical failure of OOP. No amount of late attempts at co-opting other paradigms under the OOP umbrella is going to fix that. I for one welcome the quiet morphing of OOP into VOP/FP. Makes life as a programmer sane again. [0] https://en.wikipedia.org/wiki/Object_(computer_science) https://en.wikipedia.org/wiki/Object_(computer_science)