3 ms·
> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tel
by losteric 6y ago
> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.
You seem confident in this position - can you provide some resources for others to become more familiar with that philosophy, proofs against OOP, and/or alternative approaches to architecture?
- dnautics 6y agoYeah, if you've ever worked in a functional language, console'd into and looked at data in flight, and instantly identified what was wrong because data from someone else's library wasn't encapsulated behind private fields, you would never want to encapsulate anything ever again.
- renewedrebecca 6y agoEven Eclipse lets you look at private data when debugging. Besides that though, you don't have to make data private- it's just common practice to do so.
- dnautics 6y ago> it's just common practice to do so - key point is that is that it's common practice, and the situation you're in is debugging data emitted by someone else.
- dpc_pw 6y agoPlease see https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 for description how OOP + ORM business code falls apart in practice, then https://dpc.pw/opportunistic-programming https://dpc.pw/opportunistic-programming for what I encourage. Then more posts there if you're still interested.
- losteric 6y agoThe first isn't really a critique of OOP. It's a critique of ORMs that doesn't recognize ORMs are not OOP despite the name - they initialize state that languages refer to as "objects", but those do not offer true abstractions. The second link is good, but it's just describing OOP done right. If you read the original publications, way back, OOP was never about idiomatically programming in Things - the typical example of "Dog extends Animal" is antithetical. Objects should be closer to microservices. Within those objects... stateless transforms and simple state containers (like structs), or some spaghetti. Didn't matter, the other objects should never interact below the interface.