Conceptly
← All Concepts
πŸ“¦

Object

FoundationsA concrete runtime instance

An object is the runtime instance created from a class. Even when two objects come from the same class, each can hold different state, and that state can change the result of the same method call.

β–ΆArchitecture Diagram

πŸ”— Relationship

Dashed line animations indicate the flow direction of data or requests

Why do you need it?

If data only lives in globals or detached records, it becomes unclear which values belong together and who is responsible for keeping them valid. That makes it much harder to trace the impact of changes through the system.

Why did this approach emerge?

Object orientation grew by treating programs not just as a sequence of calculations, but as collaborations among stateful entities. Widgets, sessions, orders, and game characters all pushed developers toward a model where each concrete thing could carry its own evolving state.

How does it work inside?

An object is usually understood through three aspects: identity, internal state, and method responses. Other code does not manipulate that state directly; it sends requests, and the object responds using its own rules and current values.

Boundaries & Distinctions

The difference between a class and an object is the difference between design and realization. The class is the shared template; the object is the concrete instance of that template at runtime.

When should you use it?

Objects work well when each instance must keep its own state, such as one order, one user, or one connection. If identity and lifecycle are not important and the data is just a simple value, a value-centric model can be simpler.

State tracking -- let each user, order, or document keep its own valuesBehavior dispatch -- the same message can produce different results based on object stateLifecycle management -- create, evolve, and discard entities one instance at a timeCollaboration modeling -- let multiple objects work together through references and messages