Instance (computer science)
View on Wikipediafrom Wikipedia
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
In computer science, an instance or token (from metalogic and metamathematics) is an occurrence of a software element that is based on a type definition. [1]: 1.3.2 When created, an occurrence is said to have been instantiated, and both the creation process and the result of creation are called instantiation.
Examples
[edit]- Class instance
- An object-oriented programming (OOP) object created from a class. Each instance of a class shares a data layout but has its own memory allocation.
- Procedural instance
- Although isn't common the use of this concept in computer science each procedure call also was considered an "instance" of the procedure in Simula. [1]: 1.3.2
- Computer instance
- An occurrence of a virtual machine which typically includes storage, a virtual CPU.
- Polygonal model
- In computer graphics, it can be instantiated in order to be drawn several times in different locations in a scene which can improve the performance of rendering since a portion of the work needed to display each instance is reused.
- Program instance
- In a POSIX-oriented operating system, it refers to an executing process. It is instantiated for a program via system calls such as fork() and exec(). Each executing process is an instance of a program which it has been instantiated from.[2]
References
[edit]- ^ a b Dahl, Ole-Johan; Myhrhaug, Bjørn; Nygaard, Kristen (1970). Common Base Language (PDF) (Report). Norwegian Computing Center. Archived from the original on 2024-09-19. Retrieved 20 August 2025.
- ^ Bach, Maurice J. (1986). The Design of the UNIX Operating System. Prentice Hall. pp. 10, 24. ISBN 0-13-201799-7. Archived from the original on 2010-03-15.
Instance (computer science)
View on Grokipediafrom Grokipedia
Object-Oriented Programming
Definition in OOP
In object-oriented programming (OOP), an instance refers to a concrete, runtime entity created from a class, embodying a unique object that encapsulates data and functionality specific to that realization. This instance serves as the tangible manifestation of the class's abstract definition, allowing multiple such entities to exist independently within a program. Each instance possesses three fundamental attributes: identity, state, and behavior. The identity provides a unique reference distinguishing it from other instances, even those of the same class, enabling direct addressing in memory. The state consists of the current values of the instance's data fields, which can vary among instances and evolve over time. Behavior is defined by the methods inherited from the class, dictating how the instance responds to messages or operations.[8] The term "instance" and its conceptual foundation originated in early OOP languages, gaining prominence through Smalltalk in the 1970s at Xerox PARC under Alan Kay, where objects were explicitly described as instances of classes with independent state and message-handling capabilities.[9] This usage was later adopted in C++, introduced by Bjarne Stroustrup in the 1980s as an extension of C to support OOP paradigms including class-based instantiation.[10] By the 1990s, it became standard in Java, where instances are explicitly created to model real-world entities with bundled state and behavior.[11] For example, in Java, the declarationCar myCar = new Car(); instantiates a Car object named myCar, which holds its own attribute values (state) like color and speed, while inheriting methods (behavior) such as drive() from the Car class.
Instance Creation and Lifecycle
In object-oriented programming, the process of creating an instance, known as instantiation, typically involves allocating memory for the new object and initializing its state. In languages like Java and C++, this is achieved using thenew keyword, which dynamically allocates memory on the heap and invokes the object's constructor to set initial values. For example, in Java, the expression new ClassName(arguments) allocates storage and returns a reference to the newly created object. Similarly, in C++, the new expression allocates memory via the global operator new and then constructs the object by calling its constructor, returning a pointer to it. Python handles instantiation differently, without an explicit new keyword; calling a class as a function, such as ClassName(arguments), creates the instance on the heap and automatically invokes the __init__ method if defined.[12][13]
Constructors play a crucial role in this process by ensuring the instance is properly initialized upon creation, setting up its internal state with provided arguments or default values. They are special methods named after the class (or __init__ in Python) that run automatically during instantiation and have no return type other than the implicit object reference or pointer. For instance, consider a simple Point class in Java:
public class Point {
private int x, y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
}
Here, Point p = new Point(3, 4); allocates the object on the heap and calls the constructor to assign the coordinates. An equivalent in Python uses __init__:
class Point:
def __init__(self, x, y):
self.x = x
self.y = y
p = Point(3, 4)
In C++, the constructor is similarly invoked after heap allocation:
class Point {
private:
int x, y;
public:
Point(int x, int y) : x(x), y(y) {}
};
Point* p = new Point(3, 4);
This initialization establishes the instance's identity and mutable state, distinguishing it from other instances of the same class. Constructors can be overloaded to support various initialization scenarios, but they must complete successfully for the instance to be usable.[14][13]
The lifecycle of an instance encompasses three primary stages: creation, usage, and destruction. During creation, as described, memory is allocated on the heap—Java's JVM heap for all objects, Python's private managed heap for Python objects, and C++'s free store via new—with references or pointers providing access without direct memory management by the programmer in most cases. In the usage stage, the instance maintains its state through method invocations, which can modify attributes or perform operations; for example, a move() method on the Point instance might update x and y based on current values, preserving the object's identity while altering its state. References to the instance are passed by value in Java and Python (copying the reference, not the object) or by pointer in C++, enabling shared access without duplicating the heap-allocated data.[15][16]
Destruction occurs when the instance is no longer needed, reclaiming heap memory to prevent leaks. In managed languages like Java and Python, automatic garbage collection handles this: Java's GC identifies unreachable objects (those without live references) and deallocates them, potentially invoking a finalize() method if overridden, though this is deprecated in favor of try-with-resources or cleaners. Python employs reference counting combined with cyclic GC to detect and deallocate objects when their reference count reaches zero or cycles are broken, calling __del__ if defined. In C++, destruction is manual; the programmer uses delete to invoke the destructor (which cleans up resources) and deallocate memory via operator delete, ensuring explicit control over the lifecycle to avoid dangling pointers or leaks. Throughout the lifecycle, heap allocation supports dynamic sizing and polymorphism, but requires careful reference management to maintain efficiency and correctness.[17]
Distinction from Class
In object-oriented programming, a class serves as an abstract template that defines the structure and behavior for a type of entity, including attributes (often called instance variables) and methods, while an instance represents a concrete, mutable realization of that class with its own specific state.[18] The class itself does not hold data values but provides the blueprint for creating and operating on instances, whereas each instance maintains independent values for the attributes defined by the class, allowing for mutability and individuality.[19] This distinction ensures that the class remains a static definition, focused on commonality, while the instance embodies runtime-specific details. A single class can produce multiple instances, each possessing its own unique state but sharing the same methods and behavioral logic inherited from the class.[20] For example, consider aBankAccount class that defines attributes like balance and methods such as deposit and withdraw; one instance, account1, might have a balance of $100, while another, account2, has a balance of $200—changes to one instance's state do not affect the others, yet both leverage the class's shared methods for operations. This separation supports encapsulation, where instance state is private and accessible only through class-defined methods, promoting modularity and reuse.[18]
The instance-class distinction underpins key OOP principles like polymorphism and inheritance, as instances enable runtime variations in behavior across related classes. Through polymorphism, instances of subclasses can be substituted for instances of a superclass, allowing a method to invoke different implementations based on the actual instance type at execution time.[21] In inheritance hierarchies, instances inherit and potentially override class behaviors, facilitating flexible, extensible systems where variations emerge dynamically via specific instances rather than rigid class definitions alone.[19]
Database Management Systems
Database Instance
In database management systems (DBMS), a database instance refers to the active runtime environment that manages data storage, retrieval, and processing, consisting of memory structures, background processes, and associated files that enable the DBMS to operate. This in-memory representation allows the DBMS to handle concurrent user requests, maintain data consistency, and perform recovery operations without directly altering the persistent database files on disk.[22][23] Key components of a database instance include shared memory pools for caching data and query plans, control files that record metadata about the database structure, redo logs for capturing transaction changes to support recovery, and background processes or services that automate maintenance tasks. For example, in Oracle Database, the System Global Area (SGA) serves as the primary shared memory pool, while background processes such as the Log Writer (LGWR) flush redo entries to disk and the Database Writer (DBWn) updates data files from the buffer cache; control files store locations of data files and redo logs, ensuring the instance can locate and mount the database. Similarly, in Microsoft SQL Server, the instance encompasses the Database Engine's buffer pool for data caching, along with services like the SQL Server service for query execution and the Log Manager for handling transaction logs, with memory allocation configurable via min/max server memory settings to optimize performance.[22][24][25] The startup process of a database instance typically begins with a cold start, where the system loads necessary structures from disk into memory to transition from an inactive state to full operation. In Oracle, this involves the STARTUP command progressing through phases: nomount to allocate the SGA and start background processes, mount to read control files and validate the database structure, and open to make data files and redo logs accessible for transactions. In SQL Server, startup occurs by initiating the SQL Server service via the Windows Service Control Manager or SQL Server Configuration Manager, which allocates memory (including the buffer pool), starts worker threads, and loads system databases like master and model to prepare for user connections. This process ensures the instance is ready to manage workloads while minimizing downtime.[22][26][23] The term "database instance" was standardized in the early relational DBMS era, with Oracle introducing it in its Version 2 release in 1979 as the first commercially available SQL-based system, and IBM DB2 adopting a similar architecture upon its announcement in 1983.[27][28]Schema vs. Instance
In relational database management systems (RDBMS), the schema serves as the logical blueprint defining the structure of the database, including tables, columns, data types, relationships, and constraints.[29] This structure is typically specified using Data Definition Language (DDL) statements, such asCREATE TABLE, which outline the framework without containing actual data values.[30] Introduced in the foundational relational model, the schema corresponds to the "relation heading," encompassing attribute names, domains, and keys to ensure data integrity and normalization.[31]
In contrast, the database instance represents the actual populated data within that schema at a specific point in time, consisting of rows (tuples) that conform to the defined structure.[31] This instance is dynamic, changing through insertions, updates, or deletions via Data Manipulation Language (DML) operations, and it is governed by the ACID properties to maintain reliability during transactions: Atomicity ensures all operations complete or none do; Consistency preserves schema-defined rules; Isolation prevents interference between concurrent transactions; and Durability guarantees committed changes persist despite failures.[32]
The primary distinction lies in their nature and usage: the schema is static and descriptive, providing a persistent template for data organization that evolves infrequently through DDL modifications, while the instance is dynamic and queryable, allowing retrieval and analysis of current data states using commands like SQL SELECT.[31] For example, an employee table schema might define columns for ID (integer primary key), Name (varchar), and Department (varchar with foreign key constraint), whereas a corresponding instance could include specific rows such as {ID: 1, Name: "Alice Smith", Department: "Engineering"}.[29] This separation enables the relational model to support data independence, where changes to the instance do not alter the schema, and vice versa, facilitating scalable and maintainable database design.[31]