Case against OOP is understated, not overstated (2020)

Other OO languages don't have lots of explicit factories. I'm thinking Objective-C (abstract classes can choose the appropriate subclass for new objects), Python (packages tend to have instantiation functions), Ruby (very flexible), CLOS, etc. So the factory is really a design pattern that popped up to address a specific language deficiency caused by losing a lesson discovered in the late 70s (metaclasses).

Other design patterns are really quite useful and I don't see how they can be called deficiencies. Facades, for example, are widely used in OO and non-OO systems. Template method is duplicated similarly in procedural languages that allow dynamic dispatch, in any place where you need a policy that delegates parts of its fulfillment to a more dynamically selectable part. Iterators, strategies, these things have widespread use. Builder and Prototype are frequently used outside of OO. Adapter, Bridge and Proxy also appear in various ways without OO. Many of the other patterns are OO specific mainly because there is no desire to send a message to an object in other languages. For example, Flyweight is unnecessary if you don't send messages to objects.

Without OO, a lot of domains would end up with some sort of implementation of the same thing. OO itself is a pattern in this sense. You can write Javascript in a functional way, but it makes sense to encapsulate the HTML AST and not have its memory manipulated directly by the language. Does it make a lot of difference whether you put the node as the first parameter to a function or whether you use it as the target of a message? As some functions apply to only certain kinds of nodes, does it make more sense to document those functions by the list of known nodes that they apply to, or as a hierarchy of nodes?

People often say that inheritance is the problem, but you look at a successful (in terms of utility) object system like Smalltalk and it has quite a lot of inheritance. Refactoring leads to that. Sometimes a parent class might exist just to provide one implementation of a single method for two different kinds of object. Whether this is accomplished through inheritance, mix-ins, monkey-patching, protocols, multiple dispatch, or whatever, is somewhat immaterial. But when a language makes that difficult, and you have to copy-paste to get the same functionality in multiple places, that can be a problem.

Both have good techniques, that shine for certain types of problems.

The more important thing is how you do it, how good you are at it.

It's the same thing with e.g. Agile, some people make a mess of anything including agile, some people do it well, and the vast majority of average people get average results with Agile.

So don't waste time getting stuck on one particular school of evangelism, try a range of techniques and get good enough at all so you can match the ideal technique to the specific solution you're creating.

Rust doesn't have object inheritance. So Car and Truck can't inherit from a class named Vehicle. However its Traits have inheritance, so for Car and Truck you could write implementations of a trait named Vehicle or a trait MotorTransport which inherits from Vehicle (and so you'd need to implement Vehicle too in this case as MotorTransport relies on that).

Rust only allows the author of Boat or the author of the trait Vehicle to implement Vehicle for Boat, so if you were to add a sinks_in_water() predicate to Vehicle either:

* As author of Vehicle you're responsible for implementing sinks_in_water() for Boats OR

* You've made a backwards incompatible change, anybody who uses the existing Boat can't upgrade to your revised Vehicle OR

* inside your own system where nothing external can force the version requirement, now it doesn't compile because Boat claims to implement Vehicle but it lacks sinks_in_water()