5 ms·
> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. I've never found myself thinking t
by mercer 5y ago
> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world.
I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a property.
The idea that my coffee machine is making coffee, or that my combo-oven is making my food is perhaps a bit more palatable, but even then it's now how I think about things. I am the one making coffee, or heating up food, and the actions needed are not inherently part of the object.
IMO, the problem is that people do NOT think about the world in terms of objects, at least not in a way that conforms to what is generally considered OOP. Rather, when we think of 'objects' we generally think of data structures that we then operate on. The idea that there are objects that contain both properties/state and behavior is pretty weird irl.
- acdha 5y agoOn the other hand, when you make coffee you probably aren’t thinking about how to heat the water, measure the temperature, adjust the flow rate, etc. When you use the microwave you don’t think about cycling the magnetron to hit the power level appropriate for the settings or spin the turntable. When you drive a car, you accelerate, brake, steer, etc. without directly manipulating all of the parts & microcontrollers which respond to those control changes. You just call coffeemaker.brew(), oven.defrost(“meat”, “500g”), or car.accelerate(). From that perspective the OOP model works pretty well.
- ratww 5y agoAbstraction is good, but it's not a feature specific of OOP, though. From the perspective of Procedural Programming this also works well: brew(coffeemaker), defrost(oven, "meat", "500g"), accelerate(car). Same for FP: brewed(grains), defrosted(meat, time), withAcceleration(car).
- acdha 5y agoNobody was claiming that it was unique - if you reread the thread, I was just pointing out that the dismissal of OOP not fitting the way people thinking about the world wasn’t necessarily approaching it correctly.
- ratww 5y agoNo. Your own post your reply doesn't address any of GPs dismissals about OOP, it merely incorrectly attributes the advantages of abstraction itself ("you probably aren’t thinking about how to heat the water") to OOP.
- kaba0 5y agoIn your first paragraph you have examples where you are indeed the actor. In the case of the coffee machine though, you are only the actor initiating an action (eg. the main method calling a given CoffeeMachine’s createCoffee method). And here is the great thing about OOP, you don’t have to know what exactly happens inside the machine, the way it heats up water, grinds coffee beans, etc, you only know what result you want and how to initiate an action, everything else is the responsibility of the machine. And frankly, I don’t see the divide between “data structures and how we operate on them” vs OOP. They are not mutually exclusive. Some problems are data-first, others are behavior-first — so just be familiar with both and use the correct tool for the problem.
- cout 5y agoI agree; many OO models are built in a contorted way that does not reflect reality. Still, the fact that you refer to the coffee machine as a noun and not a process tells me that you do think of that device as an object. And yes you do put the water into the machine and turn it on, then it produces coffee as an output. Some people might rightly say that makes it a function; others might rightly say that makes it an opaque object. That both views are common tells me that there is something natural about both ways of thinking.