An object in programming is a runtime entity that combines data, identity and, in many programming models, behaviour. In object-oriented programming, an object is commonly an instance of a class, although objects can also exist in prototype-based or other object systems without being instances of a conventional class. An object may contain fields or properties representing its state and methods representing operations that can be performed on or through it.
For example, a Person object might contain a name and age and provide methods for changing or reporting information. The precise semantics of an object vary by programming language, but the concept generally provides a way to represent a distinct entity that a program can create, access, modify or pass between components.
Object identity is an important distinction between an object and merely equal data. Two objects can contain identical values while still being separate objects with different identities. If one object is modified, the other does not necessarily change unless both variables or references identify the same underlying object. This distinction is especially important in languages where variables contain references to objects. Equality may mean value equality, identity equality or some language-specific comparison depending on the operator and type involved. For example, two independently created objects might represent the same conceptual information while remaining distinct runtime entities. Identity is therefore a fundamental part of understanding aliases, mutation, copying, references and object lifetime.
Objects commonly have state, behaviour and identity. State consists of the current values associated with the object, such as the fields of a customer object. Behaviour consists of operations that can inspect or modify that state, commonly implemented as methods. Identity distinguishes one object from another even if their states are equal. These three aspects are often used as a conceptual model for object-oriented programming, although actual language semantics can be more nuanced.
Some objects are immutable, meaning that their observable state cannot be changed after creation. Other objects are mutable and can undergo state transitions during execution. Immutable objects can simplify concurrent programming and reasoning about program behaviour because references to the object cannot observe arbitrary internal changes.
Objects are frequently accessed through variables or references rather than copied in their entirety for every operation. The exact model differs among languages. In Java, for example, variables of class types hold references to objects, while primitive variables hold primitive values. Python variables are names bound to objects, and assignment generally binds another name to the same object rather than copying it. In C++, objects can be stored directly in variables and can also be accessed through pointers or references. These differences make statements such as “objects are passed by reference” potentially misleading when applied universally. Correct reasoning requires understanding the language's actual argument-passing and assignment semantics.
Object construction creates an object according to the rules of its type or object system. In class-based languages, a constructor commonly establishes initial state and may allocate or initialise resources. In garbage-collected languages, an object can remain alive as long as it is reachable according to the runtime's reachability rules. In languages with manual memory management, the programmer may be responsible for explicitly releasing allocated resources or memory.
Resource lifetime and object lifetime are related but not identical: a file handle, database connection or operating-system resource may need explicit management even in a garbage-collected language. Modern approaches such as deterministic resource management, ownership systems, smart pointers and context managers address this issue in different ways.
Objects are central to encapsulation and polymorphism. Encapsulation allows an object to expose operations while hiding internal representation, and polymorphism allows code to interact with different concrete objects through a common interface or abstraction. For example, code might invoke a draw operation on objects representing different graphical shapes without requiring the caller to know each shape's internal implementation. Dynamic dispatch determines which method implementation is selected at runtime in languages that support runtime polymorphism. Composition allows objects to collaborate by containing or referencing other objects. These mechanisms permit complex systems to be decomposed into components with defined responsibilities and interactions, although excessive object coupling can make systems difficult to maintain.
Objects are not limited to abstract domain entities such as customers or vehicles. Strings, arrays, functions, database connections, network requests, user-interface controls and collections can all be represented as objects in languages that provide object semantics for them. Some languages distinguish primitive values from objects, while others treat nearly everything as an object. JavaScript, for example, has an object model based strongly on prototypes, while Python provides a broad object model in which classes, functions and many other entities are objects. Consequently, “object” is a language-dependent technical term rather than a synonym for “class instance” in every programming environment.
Objects can be compared with simpler values such as integers and strings because both ultimately represent information used by programs, but objects usually provide richer structure, identity and behaviour. An object can aggregate multiple values and expose operations over them, whereas a scalar value normally represents one conceptual value. Object-oriented programming uses objects as runtime participants in a system, while other paradigms may prefer functions and immutable data structures. The object concept remains important even outside strictly object-oriented languages because references, structured data, encapsulation and runtime entities appear across many programming models. Understanding objects therefore requires attention to identity, state, behaviour, lifetime, references and the specific semantics of the programming language being used.
