Because an object is the run-time representation of a (presumably) well-understood real-world entity, objects enhance understandability of software by leveraging our understanding of the real world.
A run-time instance of the HullCharacteristics abstraction might appear as follows:
| Field Values | Methods |
| 425.0 (lbp) |
setLBP (float) float getLBP( ) |
| 425.0 (lwl) |
setLWL (float) float getLWL( ) |
| 442.0 (loa) |
setLOA (float) float getLOA( ) |
| 57.0 (b) |
setBeam (float) float getBeam( ) |
| 42.0 (h) |
setDepth (float) float getDepth( ) |
| 28.0 (d) |
setDraft (float) float getDraft( ) |
| 0.775 (cb) |
setCB (float) float getCB( ) |
| 0.782 (cp) |
setCP (float) float getCP( ) |
In the above table, the text in green is explanatory only and would not appear in an actual run-time object memory block; only the information in black would appear in an actual object.
Note that the object contains two kinds of information:
Most programs will consist of many objects, including multiple objects of a given type. A shipping simulation program, for example, might contain many HullCharacteristics objects similar to the above, one per ship. Each HullCharacteristics object would have different values for its field data (as appropriate for modeling a given ship in the simulation) but an identical structure (the same number and types of variables, and the same methods).
Because the methods are the same for each object of the same type, objects are typically implemented such that a complete in-memory definition of the methods is not stored with each object, as this would be very wasteful of memory. Rather, a complete in-memory definition of each method is stored in a single location, and a short reference (such as the memory address) of the method is stored in the object. Regardless of the implementation details, however, the important point is that each object knows both the values of its field data, and what methods it has available to operate on that data.