3 ms·
Because most programs aren't simulators, and there often isn't a natural way to map the concepts involved in an application to that of the real world. When you
by m0th87 16y ago
Because most programs aren't simulators, and there often isn't a natural way to map the concepts involved in an application to that of the real world. When you move beyond the garbage examples they give in computer science 101 ("RaceCar extends Car") you realize objects still have their place, just not in the way the professors taught you.
- narag 16y agoI believe that the success of OOP is more a matter of usability (for the programmer) than a connection with real world models. Simpler syntax and state conservation are in fact more intuitive to use than previous ways. Only if one tries to identify at all costs programming objects with real world objects, it reveals as a leaky abstraction.
- forinti 16y agoI think that people tend to fuse two different things in their designs. The first is the model that represents the real world and the second is the structure needed for software to work. "RaceCar extends Car" is perfectly ok for modeling the entities involved. But writing a paint() method into Car or RaceCar is stupid. You need Visitors, Actions, Dispatchers, DAOs and whatnot for your programs to have a sensible and maintainable structure.
- jrockway 16y agoThis is how the real world works too. Cars cannot paint themselves.
- jimbokun 16y agoRight, you need a CarPainter. Or, maybe a Painter<Car>?
- forinti 16y agoIn reality we don't have to have to paint ourselves on canvases so that others might see us.
- jrockway 16y agoBut things do have to be moved to where people can observe them. If a tree falls in a forest...
- silentbicycle 16y agoDoes the forest have an Observer?
- adelle 16y agoMVC
- m0th87 16y agoThe car example works perfectly fine if you're modeling cars. But my point is very few applications work along these simulative lines at all.