Class (programming)

Object lifecycle

As an instance of a class, an object is constructed from a class via instantiation. Memory is allocated and initialized for the object state and a reference to the object is provided to consuming code. The object is usable until it is destroyed – its state memory is de-allocated.

Most languages allow for custom logic at lifecycle events via a constructor and a destructor.

Type

An object expresses data type as an interface – the type of each member variable and the signature of each member function (method). A class defines an implementation of an interface, and instantiating the class results in an object that exposes the implementation via the interface.^[4] In the terms of type theory, a class is an implementation‍—‌a concrete data structure and collection of subroutines‍—‌while a type is an interface. Different (concrete) classes can produce objects of the same (abstract) type (depending on type system). For example, the type (interface) Stack might be implemented by SmallStack that is fast for small stacks but scales poorly and ScalableStack that scales well but has high overhead for small stacks.

Structure

A class contains data field syntactically described (or properties, fields, data members, or attributes).^[1] These are usually field types and names that will be associated with state variables at program run time; these state variables either belong to the class or specific instances of the class. In most languages, the structure defined by the class determines the layout of the memory used by its instances. Other implementations are possible: for example, objects in Python use associative key-value containers.^[5]

Some programming languages such as Eiffel support specification of invariants as part of the definition of the class, and enforce them through the type system. Encapsulation of state is necessary for being able to enforce the invariants of the class.

Behavior

The behavior (or action^[1]) of a class or its instances is defined using methods. Methods are subroutines with the ability to operate on objects or classes. These operations may alter the state of an object or simply provide ways of accessing it.^[6] Many kinds of methods exist, but support for them varies across languages. Some types of methods are created and called by programmer code, while other special methods—such as constructors, destructors, and conversion operators—are created and called by compiler-generated code. A language may also allow the programmer to define and call these special methods.^[7][8]

Interface

Every class implements (or realizes) an interface by providing structure and behavior. Structure consists of data and state, and behavior consists of code that specifies how methods are implemented.^[9] There is a distinction between the definition of an interface and the implementation of that interface; however, this line is blurred in many programming languages because class declarations both define and implement an interface. Some languages, however, provide features that separate interface and implementation. For example, an abstract class can define an interface without providing an implementation.

Languages that support class inheritance also allow classes to inherit interfaces from the classes that they are derived from.

For example, if "class Z" inherits from "class Y" and if "class Y" implements the interface "interface X" then "class Z" also implements the functionality(constants and methods declaration) provided by "interface X".

In languages that support access specifiers, the interface of a class is considered to be the set of public members of the class, including both methods and attributes (via implicit getter and setter methods); any private members or internal data structures are not intended to be depended on by external code and thus are not part of the interface.

Object-oriented programming methodology dictates that the operations of any interface of a class are to be independent of each other. It results in a layered design where clients of an interface use the methods declared in the interface. An interface places no requirements for clients to invoke the operations of one interface in any particular order. This approach has the benefit that client code can assume that the operations of an interface are available for use whenever the client has access to the object.^[10]

Member accessibility

The following is a common set of access specifiers:^[11]

• Private (or class-private) restricts access to the class itself. Only methods that are part of the same class can access private members.
• Protected (or class-protected) allows the class itself and all its subclasses to access the member.
• Public means that any code can access the member by its name.

Although many object-oriented languages support the above access specifiers, their semantics may differ.

Object-oriented design uses the access specifiers in conjunction with careful design of public method implementations to enforce class invariants—constraints on the state of the objects. A common usage of access specifiers is to separate the internal data of a class from its interface: the internal structure is made private, while public accessor methods can be used to inspect or alter such private data.

Access specifiers do not necessarily control visibility, in that even private members may be visible to client external code. In some languages, an inaccessible but visible member may be referred to at runtime (for example, by a pointer returned from a member function), but an attempt to use it by referring to the name of the member from the client code will be prevented by the type checker.^[12]

The various object-oriented programming languages enforce member accessibility and visibility to various degrees, and depending on the language's type system and compilation policies, enforced at either compile time or runtime. For example, the Java language does not allow client code that accesses the private data of a class to compile.^[13] In the C++ language, private methods are visible, but not accessible in the interface; however, they may be made invisible by explicitly declaring fully abstract classes that represent the interfaces of the class.^[14]

Some languages feature other accessibility schemes:

• Instance vs. class accessibility: Ruby supports instance-private and instance-protected access specifiers in lieu of class-private and class-protected, respectively. They differ in that they restrict access based on the instance itself, rather than the instance's class.^[15]
• Friend: C++ supports a mechanism where a function explicitly declared as a friend function of the class may access the members designated as private or protected.^[16]
• Path-based: Java supports restricting access to a member within a Java package, which is the logical path of the file. However, it is a common practice when extending a Java framework to implement classes in the same package as a framework class to access protected members. The source file may exist in a completely different location, and may be deployed to a different .jar file, yet still be in the same logical path as far as the JVM is concerned.^[11]

Compositional

Classes can be composed of other classes, thereby establishing a compositional relationship between the enclosing class and its embedded classes. Compositional relationship between classes is also commonly known as a has-a relationship.^[20] For example, a class Car could be composed of and contain a class Engine. Therefore, a Car has an Engine. One aspect of composition is containment, which is the enclosure of component instances by the instance that has them. If an enclosing object contains component instances by value, the components and their enclosing object have a similar lifetime. If the components are contained by reference, they may not have a similar lifetime.^[21] For example, in Objective-C 2.0:

@interface Car : NSObject

@property NSString *name;
@property Engine *engine
@property NSArray *tires;

@end

This Car class has an instance of NSString (a string object), Engine, and NSArray (an array object).

Hierarchical

Classes can be derived from one or more existing classes, thereby establishing a hierarchical relationship between the derived-from classes (base classes, parent classes or superclasses) and the derived class (child class or subclass) . The relationship of the derived class to the derived-from classes is commonly known as an is-a relationship.^[22] For example, a class 'Button' could be derived from a class 'Control'. Therefore, a Button is a Control. Structural and behavioral members of the parent classes are inherited by the child class. Derived classes can define additional structural members (data fields) and behavioral members (methods) in addition to those that they inherit and are therefore specializations of their superclasses. Also, derived classes can override inherited methods if the language allows.

Not all languages support multiple inheritance. For example, Java allows a class to implement multiple interfaces, but only inherit from one class.^[23] If multiple inheritance is allowed, the hierarchy is a directed acyclic graph (or DAG for short), otherwise it is a tree. The hierarchy has classes as nodes and inheritance relationships as links. Classes in the same level are more likely to be associated than classes in different levels. The levels of this hierarchy are called layers or levels of abstraction.

Example (Simplified Objective-C 2.0 code, from iPhone SDK):

@interface UIResponder : NSObject //...
@interface UIView : UIResponder //...
@interface UIScrollView : UIView //...
@interface UITableView : UIScrollView //...

In this example, a UITableView is a UIScrollView is a UIView is a UIResponder is an NSObject.

Modeling

In object-oriented analysis and in Unified Modelling Language (UML), an association between two classes represents a collaboration between the classes or their corresponding instances. Associations have direction; for example, a bi-directional association between two classes indicates that both of the classes are aware of their relationship.^[24] Associations may be labeled according to their name or purpose.^[25]

An association role is given end of an association and describes the role of the corresponding class. For example, a "subscriber" role describes the way instances of the class "Person" participate in a "subscribes-to" association with the class "Magazine". Also, a "Magazine" has the "subscribed magazine" role in the same association. Association role multiplicity describes how many instances correspond to each instance of the other class of the association. Common multiplicities are "0..1", "1..1", "1..*" and "0..*", where the "*" specifies any number of instances.^[24]

Abstract and concrete

In a language that supports inheritance, an abstract class, or abstract base class (ABC), is a class that cannot be directly instantiated. By contrast, a concrete class is a class that can be directly instantiated. Instantiation of an abstract class can occur only indirectly, via a concrete subclass.

An abstract class is either labeled as such explicitly or it may simply specify abstract methods (or virtual methods). An abstract class may provide implementations of some methods, and may also specify virtual methods via signatures that are to be implemented by direct or indirect descendants of the abstract class. Before a class derived from an abstract class can be instantiated, all abstract methods of its parent classes must be implemented by some class in the derivation chain.^[26]

Most object-oriented programming languages allow the programmer to specify which classes are considered abstract and will not allow these to be instantiated. For example, in Java, C# and PHP, the reserved word (keyword) abstract is used.^[27][28] In C++, an abstract class is a class having at least one abstract method given by the appropriate syntax in that language (a pure virtual function in C++ parlance).^[26]

A class consisting of only pure virtual methods is called a pure abstract base class (or pure ABC) in C++ and is also known as an interface by users of the language.^[14] Other languages, notably Java and C#, support a variant of abstract classes called an interface via a keyword in the language. In these languages, multiple inheritance is not allowed, but a class can implement multiple interfaces. Such a class can only contain abstract publicly accessible methods.^[23][29][30]

Local and inner

In some languages, classes can be declared in scopes other than the global scope. There are various types of such classes.

An inner class is a class defined within another class. The relationship between an inner class and its containing class can also be treated as another type of class association. An inner class is typically neither associated with instances of the enclosing class nor instantiated along with its enclosing class. Depending on the language, it may or may not be possible to refer to the class from outside the enclosing class. A related concept is inner types, also known as inner data type or nested type, which is a generalization of the concept of inner classes. C++ is an example of a language that supports both inner classes and inner types (via typedef declarations).^[31][32]

A local class is a class defined within a procedure or function. Such structure limits references to the class name to within the scope where the class is declared. Depending on the semantic rules of the language, there may be additional restrictions on local classes compared to non-local ones. One common restriction is to disallow local class methods to access local variables of the enclosing function. For example, in C++, a local class may refer to static variables declared within its enclosing function, but may not access the function's automatic variables.^[33]

Metaclass

A metaclass is a class where instances are classes.^[34] A metaclass describes a common structure of a collection of classes and can implement a design pattern or describe particular kinds of classes. Metaclasses are often used to describe frameworks.^[35]

In some languages, such as Python, Ruby or Smalltalk, a class is also an object; thus each class is an instance of a unique metaclass that is built into the language.^{[5][36] [37]} The Common Lisp Object System (CLOS) provides metaobject protocols (MOPs) to implement those classes and metaclasses.^[38]

Final

A final class cannot be subclassed. It is basically the opposite of an abstract class, which must be subclassed to be used and cannot be instantiated directly. A final class is implicitly a concrete class, can be instantiated directly.

A class is declared as final via the keyword final in Java, C++ or PHP, or sealed in C#. However, this concept should not be confused with classes in Java qualified with the keyword sealed, that only allow inheritance from selected subclasses.^{[39][40][41][42]} In languages like Kotlin, all classes are final by default, while to allow a class to be inherited from, it must instead be marked open.^[43]

For example, Java's String class is marked as final.^[44]

Final classes may allow a compiler to perform optimizations that are not available for classes that can be subclassed.^[45]

Sealed

A "sealed class" is a class that restricts inheritance to a selected list of classes. It should not be confused with the sealed keyword in C#, which denotes a final class. The list of permitted classes the sealed class may inherit is specified using a permits clause.^[46]

public sealed class Quadrilateral 
    extends Shape 
    implements Renderable, Transformable, Comparable<Quadrilateral>, Measurable
    permits Parallelogram, Trapezoid, Kite {
    // ...
}

non-sealed is another keyword used to declare that a class or interface which extends a sealed class can be extended by unknown classes.^[47]

sealed class Parallelogram extends Quadrilateral { /* ... */ }
sealed class Rectangle extends Parallelogram { /* ... */ }

non-sealed class Square extends Rectangle { /* ... */ }

// Because Square is non-sealed, any class can inherit from it
class RedSquare extends Square { /* ... */ }

Open

An open class can be changed. Typically, an executable program cannot be changed by customers. Developers can often change some classes, but typically cannot change standard or built-in ones. In Ruby, all classes are open. In Python, classes can be created at runtime, and all can be modified afterward.^[48] Objective-C categories permit the programmer to add methods to an existing class without the need to recompile that class or even have access to its source code.

Mixin

Some languages have special support for mixins, though, in any language with multiple inheritance, a mixin is simply a class that does not represent an is-a-type-of relationship. Mixins are typically used to add the same methods to multiple classes; for example, a class UnicodeConversionMixin might provide a method called unicodeToAscii() when included in classes FileReader and WebPageScraper that do not share a common parent.

Partial

In languages supporting the feature, a partial class is a class whose definition may be split into multiple pieces, within a single source-code file or across multiple files.^[49] The pieces are merged at compile time, making compiler output the same as for a non-partial class.

The primary motivation for the introduction of partial classes is to facilitate the implementation of code generators, such as visual designers.^[49] It is otherwise a challenge or compromise to develop code generators that can manage the generated code when it is interleaved within developer-written code. Using partial classes, a code generator can process a separate file or coarse-grained partial class within a file, and is thus alleviated from intricately interjecting generated code via extensive parsing, increasing compiler efficiency and eliminating the potential risk of corrupting developer code. In a simple implementation of partial classes, the compiler can perform a phase of precompilation where it "unifies" all the parts of a partial class. Then, compilation can proceed as usual.^[50]

Other benefits and effects of the partial class feature include:

• Enables separation of a class's interface and implementation code in a unique way.
• Eases navigation through large classes within an editor.
• Enables separation of concerns, in a way similar to aspect-oriented programming but without using any extra tools.
• Enables multiple developers to work on a single class concurrently without the need to merge individual code into one file at a later time.

Partial classes have existed in Smalltalk under the name of Class Extensions for considerable time. With the arrival of the .NET framework 2, Microsoft introduced partial classes, supported in both C# 2.0 and Visual Basic 2005. WinRT also supports partial classes.^[51]

Uninstantiable

Uninstantiable classes allow programmers to group together per-class fields and methods that are accessible at runtime without an instance of the class. Indeed, instantiation is prohibited for this kind of class.

For example, in C#, a class marked static can not be instantiated, can only have static members (fields, methods, other), may not have instance constructors, and is sealed (is final). ^[52]

Unnamed

An unnamed class or anonymous class is not bound to a name or identifier upon definition.^[53][54] This is analogous to named versus unnamed functions.

interface Greeting {
    void sayHello();
}

// Anonymous class that implements Greeting
Greeting myGreeting = new Greeting() {
    @Override
    public void sayHello() {
        System.out.println("Hello from an anonymous class!");
    }
};

myGreeting.sayHello();

Encapsulation

Encapsulation prevents users from breaking the invariants of the class, which is useful because it allows the implementation of a class of objects to be changed for aspects not exposed in the interface without impact to user code. The definitions of encapsulation focus on the grouping and packaging of related information (cohesion) rather than security issues.

Critique

Class-based languages, or, to be more precise, typed languages, where subclassing is the only way of subtyping, have been criticized for mixing up implementations and interfaces—the essential principle in object-oriented programming. The critics say one might create a bag class that stores a collection of objects, then extend it to make a new class called a set class where the duplication of objects is eliminated.^[61][62] Now, a function that takes an object of the bag class may expect that adding two objects increases the size of a bag by two, yet if one passes an object of a set class, then adding two objects may or may not increase the size of a bag by two. The problem arises precisely because subclassing implies subtyping even in the instances where the principle of subtyping, known as the Liskov substitution principle, does not hold. Barbara Liskov and Jeannette Wing formulated the principle succinctly in a 1994 paper as follows:

Subtype Requirement: Let ⁠${\displaystyle \phi (x)}$⁠ be a property provable about objects ⁠${\displaystyle x}$⁠ of type ⁠${\displaystyle T}$⁠. Then ⁠${\displaystyle \phi (y)}$⁠ should be true for objects ⁠${\displaystyle y}$⁠ of type ⁠${\displaystyle S}$⁠ where ⁠${\displaystyle S}$⁠ is a subtype of ⁠${\displaystyle T}$⁠.

Thus, normally one must distinguish subtyping and subclassing. Most current object-oriented languages distinguish subtyping and subclassing, however some approaches to design do not.

Also, another common example is that a person object created from a child class cannot become an object of parent class because a child class and a parent class inherit a person class but class-based languages mostly do not allow to change the kind of class of the object at runtime. For class-based languages, this restriction is essential in order to preserve unified view of the class to its users. The users should not need to care whether one of the implementations of a method happens to cause changes that break the invariants of the class. Such changes can be made by destroying the object and constructing another in its place. Polymorphism can be used to preserve the relevant interfaces even when such changes are done, because the objects are viewed as black box abstractions and accessed via object identity. However, usually the value of object references referring to the object is changed, which causes effects to client code.

Example languages

Although Simula introduced the class abstraction, the canonical example of a class-based language is Smalltalk. Others include PHP, C++, Java, C#, and Objective-C. ^{[dubious – discuss][non sequitur]}