Классы и объекты в объектно-ориентированном программировании.

Definition in programming that specifies how an object works
In object oriented programming, a class is an extensible program code template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods). When an object is created by a constructor of the class, the resulting object is called an instance of the class, and the member variables specific to the object are called instance variables, to contrast with the class variables shared across the class. In some programming languages, classes are a compile time feature only (new classes cannot be declared at runtime). In other languages, classes are first class citizens, and are generally objects (typically of type or similar). In these languages, a class that creates classes within itself is called a metaclass.

In object oriented programming (OOP), an instance is a concrete occurrence of any object, existing usually during the runtime of a computer program. Formally, "instance" is synonymous with "object" as they are each a particular value (realization), and these may be called an instance object; "instance" emphasizes the distinct identity of the object. The creation of an instance is called instantiation. An object may be varied in many ways. Each realized variation of that object is an instance of its class. That is, it is a member of a given class that has specified values rather than variables. In a non programming context, you could think of "dog" as a type and your particular dog as an instance of that class. In class based programming, objects are created as instances of classes by subroutines called constructors, and destroyed by destructors. An object is an instance of a class as it can access to all data types(primitive as well as non primitive), and methods etc., of a class. Therefore, objects may be called a class instances or class objects. Object instantiation is known as construction. Not all classes can be instantiated abstract classes cannot be instantiated, while classes that can be instantiated are called concrete classes. In prototype based programming, instantiation is instead done by copying (cloning) a prototype instance.

In its most casual usage, people often refer to the "class" of an object, but narrowly speaking objects have type: the interface, namely the types of member variables, the signatures of member functions (methods), and properties these satisfy. At the same time, a class has an implementation (specifically the implementation of the methods), and can create objects of a given type, with a given implementation. In the terms of type theory, a class is an implementationa concrete data structure and collection of subroutineswhile a type is an interface. Different (concrete) classes can produce objects of the same (abstract) type (depending on type system); for example, the type might be implemented with two classes (fast for small stacks, but scales poorly) and (scales well but high overhead for small stacks). Similarly, a given class may have several different constructors. Class types generally represent nouns, such as a person, place or thing, or something nominalized, and a class represents an implementation of these. For example, a type might represent the properties and functionality of bananas in general, while the and classes would represent ways of producing bananas (say, banana suppliers or data structures and functions to represent and draw bananas in a video game). The class could then produce particular bananas: instances of the class would be objects of type Often only a single implementation of a type is given, in which case the class name is often identical with the type name.

Classes are composed of structural and behavioral constituents. Programming languages that include classes as a programming construct offer support, for various class related features, and the syntax required to use these features varies greatly from one programming language to another.

A class contains data field descriptions (or properties, fields, data members, or attributes). 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. 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.

The behavior 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. 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.

Conceptually, a superclass is a superset of its subclasses. For example, a common class hierarchy would involve as a superclass of and , while would be a subclass of These are all subset relations in set theory as well, i. e., all squares are rectangles but not all rectangles are squares. A common conceptual error is to mistake a part of relation with a subclass. For example, a car and truck are both kinds of vehicles and it would be appropriate to model them as subclasses of a vehicle class. However, it would be an error to model the parts of the car as subclass relations. For example, a car is composed of an engine and body, but it would not be appropriate to model an engine or body as a subclass of a car. In object oriented modeling these kinds of relations are typically modeled as object properties. In this example, the class would have a property called would be typed to hold a collection of objects, such as instances of , , , etc. Object modeling languages such as UML include capabilities to model various aspects of "part of" and other kinds of relations – data such as the cardinality of the objects, constraints on input and output values, etc. This information can be utilized by developer tools to generate additional code besides the basic data definitions for the objects, such as error checking on get and set methods. One important question when modeling and implementing a system of object classes is whether a class can have one or more superclasses. In the real world with actual sets, it would be rare to find sets that did not intersect with more than one other set. However, while some systems such as Flavors and CLOS provide a capability for more than one parent to do so at run time introduces complexity that many in the object oriented community consider antithetical to the goals of using object classes in the first place. Understanding which class will be responsible for handling a message can get complex when dealing with more than one superclass. If used carelessly this feature can introduce some of the same system complexity and ambiguity classes were designed to avoid. Most modern object oriented languages such as Smalltalk and Java require single inheritance at run time. For these languages, multiple inheritance may be useful for modeling but not for an implementation. However, semantic web application objects do have multiple superclasses. The volatility of the Internet requires this level of flexibility and the technology standards such as the Web Ontology Language (OWL) are designed to support it. A similar issue is whether or not the class hierarchy can be modified at run time. Languages such as Flavors, CLOS, and Smalltalk all support this feature as part of their meta object protocols. Since classes are themselves first class objects, it is possible to have them dynamically alter their structure by sending them the appropriate messages. Other languages that focus more on strong typing such as Java and C++ do not allow the class hierarchy to be modified at run time. Semantic web objects have the capability for run time changes to classes. The rationale is similar to the justification for allowing multiple superclasses, that the Internet is so dynamic and flexible that dynamic changes to the hierarchy are required to manage this volatility.

Although class based languages are commonly assumed to support inheritance, inheritance is not an intrinsic aspect of the concept of classes. Some languages, often referred to as "object based languages", support classes yet do not support inheritance. Examples of object based languages include earlier versions of Visual Basic.

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. Associations may be labeled according to their name or purpose. 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. 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 keyword abstract is used. 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).

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). Another type is a local class, which is a class defined within a procedure or function. This 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.

Metaclasses are classes which instances are classes. 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. 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. The Common Lisp Object System (CLOS) provides metaobject protocols (MOPs) to implement those classes and metaclasses.

Non subclassable classes or sealed classes allow programmers to design classes and hierarchies of classes where at some level in the hierarchy, further derivation is prohibited (a stand alone class may be also designated as non subclassable, preventing the formation of any hierarchy). Contrast this to abstract classes, which imply, encourage, and require derivation to be used at all. A non subclassable class is implicitly concrete. A non subclassable class is created by declaring the class as in C# or as in Java or PHP. For example, Java's class is designated as final. Non subclassable classes may allow a compiler (in compiled languages) to perform optimizations that are not available for subclassable classes.

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. 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.

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 might provide a method called when included in classes and that do not share a common parent.

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. 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.

An unnamed class or anonymous class is a class that is not bound to a name or identifier upon definition. This is analogous to named versus unnamed functions.

As a data type, a class is usually considered as a compile time construct. A language or library may also support prototype or factory metaobjects that represent runtime information about classes, or even represent metadata that provides access to reflective programming (reflection) facilities and ability to manipulate data structure formats at runtime. Many languages distinguish this kind of run time type information about classes from a class on the basis that the information is not needed at runtime. Some dynamic languages do not make strict distinctions between runtime and compile time constructs, and therefore may not distinguish between metaobjects and classes. For example, if Human is a metaobject representing the class Person, then instances of class Person can be created by using the facilities of the Human metaobject.