To expand on this: The issue is that OOP easily leads you to model your problem into your solution. This has the desired effect of solving the problem, but the likely undesired side effect that your solution encodes a specific problem description.
I think the problem is not OOP - the author approached the problem bottom-up, they were trying to foresee usage for code they were writing. The resulting code is a bit of a mess, not OOP (there’s even instanceof) Instead we should start with the usage, with the code creating the value and then filling in the details. In this problem, if we choose to simulate the circuit I would start with the simulator code, introducing abstractions for components only if it would help the simulator.
I liked the demonstration of this approach in Chapter 6 of Robert C. Martin’s Agile Software Development: Principles, Patterns and Practices. It’s available online here:
There are a few problems with OOP. The one that bothers me the most is that there is immediately boilerplate complexity. How is this bag of data addressed? What does it behave like? How is each piece of it read and written? Now you need collection generics. There’s complexity everywhere, and it’s expensive. It hampers concurrency, and doesn’t work on GPUs. What do we get for it? Implicit control flow, and it isn’t even clear to me that this is a benefit let alone worth the costs. Any time performance is remotely a concern, object orientation should be the first thing removed.
Yeah. Generally the best code in OOP languages tends to favour composition over inheritance. In other words, it uses functional ideas and works around some of the clunkiness of OOP to build generic structures and algorithms. This is what really successful packages in OOP languages look like (such as numpy and friends).
Object oriented programming has ruined us