3 ms·
To paraphrase Robert Downey Jr., 'Never go "full OOP."' I think the bigger problem has been decades of education that start with decomposing domain objects int
by slowmovintarget 12y ago
To paraphrase Robert Downey Jr., 'Never go "full OOP."'
I think the bigger problem has been decades of education that start with decomposing domain objects into OOP class hierarchies by common attributes.
Animal, Dog, English Bulldog, Herman.
Now we have significantly better ways of teaching OOP:
- favor composition over inheritance
- decompose and group behaviors
- Liskov substitution principle
Sadly we're dealing with mainstream languages that are barely OO like Java (which I've done 99% of my work in for the last thirteen years). But even if Eiffel had somehow taken off and stood in Java's place... Nope... can't finish that sentence. It couldn't have.
OO was originally created as a way to cleanly allocate memory on the heap. That's a fairly well solved problem now. The best parts of OO aside from heap allocation are encapsulation and polymorphic dispatch (two sides of the same coin). Closures and functions as fundamental units of decomposition handle that fairly well, especially when you couple that with type inferencing.
I'm not arguing that OO is bad. I'm arguing that it's no longer anywhere near as useful as it used to be, even when it was implemented and used properly.
- klibertp 12y ago> OO was originally created as a way to cleanly allocate memory on the heap. That's the first time I hear something like this. Any source for this?
- slowmovintarget 12y agoI can't find the reference now, but it was part of a history I'd read about the creation of Simula 67. Given that the summaries you read on Wikipedia about it describe Simula 67 as a fulfillment of the need to create a better process description abstraction, I may simply be wrong.