Does Object Oriented Programming Really Model The Real World? [closed]alsoFirstly, A represents an object in the physical world, which is a strong argument for not splitting the class up. I was, unfortunately, told this when I started programming. It took me years to realize that it's a bunch of horse hockey. It's a terrible reason to group things. I can't articulate what are good reasons to group things (at least to my satisfaction), but that one is one you should discard right now. The end all, be all of good code is that it works right, is relatively easy to understand, and is relatively easy to change (i.e., changes don't have weird side effects).   jpmc26 8 hours agoFirstly, A represents an object in the physical world, which is a strong argument for not splitting the class up.   I disagree with this. For example, if I had a class that represents a car, I would definitely want to split it up, because I surely want a smaller class to represent the tires. -  jpmc26 11 hours agosourceUntil now, I considered the following a good design, because it emphasizes physical hierarchy among the objects. I would expect that to be easier to understand, than some abstractions e.g.class ViewManager, class WheelsFascade.class Car{public:    void start() {assert(!m_fuel_tank.empty()); m_engine.start();};private:    std::vector<Wheel> m_wheels;    Engine m_engine;    FuelTank m_fuel_tank;}Am I understanding correctly the above criticism that this is not a good design? If so, what are the actual problems? If not, what is being criticized?
When is it not acceptable to model physical world objects with classes?
object oriented
It is impossible to answer the question of whether the code you present is a good design without a good understanding of what and who the code is for. Why, exactly, do you have such a class in your application? What are its clients? Who specified the behaviours that are implemented by it? How likely are those specifications to change in future? Which aspects of the specification are likely to change together, and which are likely to change at different times?Real software rarely does something identical to a real world object, so breaking it up along similar divisions is not necessarily the best approach. Even if what we are doing is simulating a real system, it may be best to either merge components that are conceptually distinct in the real world into a single abstraction (perhaps because we don't need to model the interactions between then, but only the end result of those interactions: your model has 4 separate wheel objects, but it may make more sense to consider two wheels and an axle as a single unit, for example) or split a single real component into multiple roles (because that component does multiple things and we need to model those in different ways: a car's wheels steer the car and impart forwards motion, which we may decide is easier to handle separately than together).What we can say with certainty is that the dogma that modelling objects should be based strictly on the division of components in real world objects is clearly wrong.  We should split our code into objects for pragmatic reasons, rather than to conform to ideals that have no practical basis, which is what this suggestion appears to be.