There is a common misconception that is taught in almost every object oriented programming course and book. This misconception is that the real world is composed of macroscopic objects. The common example is a car. It has properties, like make, model, year, color, and so on. It has actions, called methods in OOP, like accelerate, brake, blink left, and more. A car is an object.
Object modeling has a strict definition for objects. If it has properties and actions, then it is an object. Essentially, properties are nouns and adjectives, and actions are verbs. By this definition, wind is an object. It has properties like temperature, direction, and speed. It has actions, like changing speed or direction and knocking things down. In real life terms though, wind is not an object. Using the object model, wind is actually more like a method of the air object. It is an action that air takes. The object model used in object oriented programming is not a reflection of real life applied to programming. It is an abstraction of human reasoning and abstraction applied to programming.
In real life, there is no solid definition of what is an object. The Merriam-Webster definition requires physical objects to be detectable with the senses, which eliminates anything microscopic, no matter how well it fits the object model definition. It also includes things, like wind, which most people would not normally consider objects. Besides all of that, it is too vague to be truly useful.
For most intents, physical objects are defined by their chemical bonds. The difference between two 1oz chunks of steel and one 2oz chunk is that one is coherently bonded in its entirety, while the other is two pieces that are coherently bonded but not to each other. The two pieces could be changed from two objects to one object by welding them together. Unfortunately, this is not a strict rule. A car is composed of many coherent but separate pieces, but it is still considered a single object.
We might define an object based on functional coherence. A board game, composed of a board, game pieces, and a pair of dice, is a single object, because all of the parts serve a single functional purpose: to play the game. A car, composed of an engine, wheels, a chassis, and so on, serves a single purpose of transportation, so it is a functionally coherent object. Except, what about the radio? That does nothing for transportation. It is still considered part of the object. It is not chemically bonded to the object, nor is it a functionally coherent part of the object, so why is the radio part of the car? Obviously functional coherence is not the answer.
Maybe we could add that something which is attached to the object is part of it. This could be viewed as a sort of non-chemical physical continuity. The radio is firmly attached to the car, probably with screws or some kind of snap in tabs. Does this mean that if my son puts super glue on my chair, and I sit on it, I become part of my chair (or maybe my chair becomes part of me)? Again, a dead end.
Even containment does not work. I can be inside my car without being part of it. Putting a CD in a computer does not make it become part of the computer (though putting a hard drive in a computer does...). Even this depends on the specifics.
The problem is that the idea of an object is just that: an idea. Objects are not real things. We perceive things as objects, because we perceive some kind of relational continuity between their parts. This is highly subjective. One person might consider the air filter or battery in the car to be part of the car object, while another might consider them to be separate objects that happen to be used in and by the car. Further, all objects are composed of other objects, until they are not anymore. Current science seems to hold that down to a quantum level all particles have properties and methods (as interactions). In reality though, as you approach sub-atomic levels, the idea of particles seems to break down entirely, giving way to matter that acts like particles but seems to be composed entirely of waves (or one giant wave) with complex harmonics. We cannot say with any degree of certainty that the object model can even be applied to particles smaller than atoms.
The point is, the object model does not reflect real life at all. It merely reflects how most humans tend to perceive real life. Now, this is still very useful, but it exposes some limitations. Because perception is subjective, two people may not always agree on how a specific idea should be modeled as an object or collection of objects. If a battery is part of the car, maybe the car should have a "charge" property to track the charge of the battery. If it is not, maybe we need a whole new "battery" object, with its own "charge" property, and then the car can have a property that points to that battery. Both models have value in specific cases, so there is no common-sense solution. In addition, not all ideas even make sense as objects. Many object oriented programs include objects that are totally incoherent collections of properties and methods that just needed to go somewhere. Besides being bad programming practice (though sometimes necessary in languages that force everything to be part of an object, like Java), this violates the entire purpose of objects. We find this sort of thing in real life all the time though. Many households have a "junk drawer" for holding miscellaneous objects that have nowhere else to go.
While the car analogy might make a good start for helping people to understand objects, very early on it would be a wise idea to stop comparing them to real life objects and start describing them as organizational units. The object model is not about modeling real life. Objects are called objects because it helps people understand the coherency that objects should have. Beyond that though, they resemble real life very poorly, and if the comparison with real life is not left behind, it is likely to result in poor programming practices and absurd arguments over design where real life is used as justification for choosing the worst solutions. In the object model, objects are containers. They are organizational units. Poor organization is poor organization, no matter how people choose to do things in real life. The car analogy is great, but when students start thinking they need to make a "FuelTank" object (and don't forget "FuelPump" and "FuelFilter"), when merely keeping track of current fuel level would be sufficient, the analogy has gone too far.
Object oriented programming is powerful and useful, but it is also far more prone to error than procedural programming. The errors found in object oriented programming are not the kind that break the program, however. They are the kind that waste resources and make maintaining the program very difficult. One of the most effective solutions to this problem would be to reveal objects for what they are, organizational units, instead of comparing them to things that they only marginally resemble, real life objects.
