Class (computer science)
7392
225038461
2008-07-11T16:16:50Z
Maian
461645
updated constructors/destructors; python constructor is not as simple as just __init__
In [[object-oriented programming]], a '''class''' is a [[programming language]] construct that is used as a blueprint to create [[Object (object-oriented programming)|object]]s. This blueprint includes [[Attribute (computing)|attribute]]s and [[Method (computer science)|method]]s that the created objects all share.
More technically, a class is a [[Cohesion (computer science)|cohesive]] package that consists of a particular kind of [[metadata]]. It describes the rules by which objects behave; these objects are referred to as [[Instantiation (computer science)|instances]] of that class. A class has both an interface and a structure. The interface describes how the class and its instances can be interacted with via methods, while the structure describes how the [[Data (computing)|data]] is partitioned into attributes within an instance. A class is the most specific [[datatype|type]] of an object in relation to a specific [[Layer (object-oriented design)|layer]]. A class may also have a representation ([[metaobject]]) at runtime, which provides runtime support for manipulating the class-related metadata.
Programming languages that support classes all subtly differ in their support for various class-related features. Most support various forms of class [[Inheritance (computer science)|inheritance]]. Many languages also support features providing [[Information hiding|encapsulation]], such as access specifiers.
== Reasons for using classes ==
Classes, when used properly, can accelerate development by reducing redundant code entry, testing and [[Software bug|bug]] [[Debugging|fixing]]. If a class has been thoroughly tested and is known to be a solid work, it stands to reason that using that well-tested class or extending it will reduce, if not eliminate, the possibility of bugs propagating into the code. In the case of extension, new code is being added, so it also requires the same level of testing before it can be considered solid.
Another reason for using classes is to simplify the relationships of interrelated data. Rather than writing code to repeatedly call a [[Graphical user interface|GUI]] [[Window (computing)|window]] drawing subroutine on the terminal screen (as would be typical for [[structured programming]]), it is more intuitive to represent the window as an object and tell it to draw itself as necessary. With classes, GUI items that are similar to windows (such as dialog boxes) can simply inherit most of their functionality and data structures from the [[window class]]. The programmer then need only add code to the dialog class that is unique to its operation. Indeed, GUIs are a very common and useful application of classes, and GUI programming is generally much easier with a good class framework.
== Instantiation ==
{{main|Instantiation (computer science)}}
A class is used to create new '''instances''' (''objects'') by '''instantiating''' the class.
Instances of a class share the same set of attributes, yet may differ in what those attributes contain. For example, a class "Person" would describe the attributes common to all instances of the Person class. Each person is generally alike, but varies in such attributes as "height" and "weight". The class would list types of such attributes and also define the actions which a person can perform: "run", "jump", "sleep", "walk", etc. One of the benefits of programming with classes is that all instances of a particular class will follow the defined behavior of the class they instantiate.
In most languages, the [[#Structure of a class|structures]] as defined by the class determine how the memory used by its instances will be laid out. This technique is known as the ''cookie-cutter model''. The alternative to the cookie-cutter model is that of for example [[Python (programming language)|Python]], where objects are structured as associative key-value containers. In such models, objects that are instances of the same class could contain different instance variables, as state can be dynamically added to the object. This may resemble [[Prototype-based languages|prototype-based languages]] in some ways, but it is not equivalent.
== Interfaces and methods ==
{{main|Interface (computer science)|Method (computer science)}}
Note: the term "interface" here isn't referring to a [[Interface (Java)|Java interface]], although the two are closely related. <!-- This section used to contain info on Java interfaces. If you wish to view it (to, say, move to another page), the last revision before the removal of this info is http://en.wikipedia.org/w/index.php?title=Class_(computer_science)&oldid=165562113 -->
Objects define their interaction with the outside world through the '''methods''' that they expose. A method, or ''instance method'', is a [[subroutine]] (function) with a special property that it has access to data stored in an object (instance). Methods that manipulate the data of the object and perform tasks are sometimes described as [[behavior]].
Methods form the object's '''interface''' with the outside world; the buttons on the front of your television set, for example, are the interface between you and the electrical wiring on the other side of its plastic casing. You press the "power" button to toggle the television on and off. In this example, the television is the instance, each method is represented by a button, and all the buttons together comprise the interface. In its most common form, an interface is a specification of a group of related methods without any associated implementation of the methods.
Every class '''implements''' (or ''realizes'') an interface by providing [[#Structure of a class|structure]] (i.e. data and state) and method implementations (i.e. providing code that specifies how methods work). There is a distinction between the definition of an interface and the implementation of that interface. In most languages, this line is usually blurred, because a class declaration both defines and implements an interface. Some languages, however, provide features that help separate interface and implementation. For example, an [[#Abstract classes|abstract class]] can define an interface without providing implementation, and in the [[Dylan (programming language)|Dylan]] language, class definitions do not even define interfaces.
Interfaces may also be defined to include a set of auxiliary functions called ''static methods'' or ''class methods''. Static methods, like instance methods, are exclusively associated with the class. They differ with instance methods in that they do not work with instances of the class; that is, static methods neither require an instance of the class nor can access the data of such an instance. For example, getting the total number of televisions in existence could be a static method of the television class. This method is clearly associated with the class, yet is outside the domain of each individual instance of the class. Another example is a static method that finds a particular instance out of the set of all television sets.
Languages that support class inheritance also allow classes to inherit interfaces from the classes that they are derived from. In languages that support [[#Information hiding and encapsulation|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 [[Mutator method|getter and setter methods]]); any private members or internal data structures are not intended to be depended on by client code and thus are not part of the interface.
The object-oriented programming methodology is designed in such a way that the operations of any interface of a class are usually chosen to be independent of each other. It results in a [[client-server]] (or layered) design where servers do not depend in any way on the clients. 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 holds a valid reference to the object.
== Structure of a class ==
[[Image:oop-uml-class-example.png|frame|right|[[Unified Modeling Language|UML]] notation for classes]]
Along with having an interface, a class contains a description of structure of [[Data (computing)|data]] stored in the instances of the class. The data is partitioned into '''attributes''' (or ''properties'', ''fields'', ''data members''). Going back to the television set example, the myriad attributes, such as size and whether it supports color, together comprise its structure. A class represents the full description of a television, including its attributes (structure) and buttons (interface).
The [[state (computer science)|state]] of an instance's data is stored in some resource, such as memory or a file. The storage is assumed to be located in a specific location, such that it is possible to access the instance through [[reference (computer science)|reference]]s to the [[identity (object-oriented programming)|identity]] of the instances. However, the actual storage location associated with an instance may change with time. In such situations, the identity of the object does not change. The state is encapsulated and every access to the state occurs through methods of the class.
A class also describes a set of [[class invariant|invariant]]s that are preserved by every method in the class. An invariant is a constraint on the state of an object that should be satisfied by every object of the class. The main purpose of the invariants is to establish what objects belong to the class. An invariant is what distinguishes [[data type]]s and classes from each other; that is, a class does not allow use of all possible values for the state of the object, and instead allows only those values that are well-defined by the semantics of the intended use of the data type. The set of supported (public) methods often implicitly establishes an invariant. Some programming languages support specification of invariants as part of the definition of the class, and enforce them through the type system. [[#Information hiding and encapsulation|Encapsulation]] of state is necessary for being able to enforce the invariants of the class.
Some languages allow an implementation of a class to specify [[constructor (computer science)|constructor]] (or ''initializer'') and [[destructor (computer science)|destructor]] (or ''finalizer'') methods that specify how instances of the class are created and destroyed, respectively. A constructor that takes arguments can be used to create an instance from passed-in data. The main purpose of a constructor is to establish the invariant of the class, failing if the invariant isn't valid. The main purpose of a destructor is to destroy the identity of the instance, invalidating any references in the process. Constructors and destructors are often used to reserve and release, respectively, resources associated with the object. In some languages, a destructor can return a value which can then be used to obtain a public representation (transfer encoding) of an instance of a class and simultaneously destroy the copy of the instance stored in current thread's memory.
A class may also contain ''static attributes'' or ''class attributes'', which contain data that are specific to the class yet are common to all instances of the class. If the class itself is treated as an instance of a hypothetical [[metaclass]], static attributes and static methods would be instance attributes and instance methods of that metaclass.
=== Run-time representation of classes ===
As a data type, a class is usually considered as a compile-time construct. A language may also support [[prototype]] or [[Factory method pattern|factory]] [[metaobject]]s that represent run-time information about classes, or even represent metadata that provides access to [[Reflection (computer science)|reflection]] facilities and ability to manipulate data structure formats at run-time. 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 run-time. Some dynamic languages do not make strict distinctions between run-time 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]].
== Information hiding and encapsulation ==
{{main|Information hiding}}
Many languages support the concept of '''information hiding''' and '''encapsulation''', typically with '''access specifiers''' for class members. Access specifiers specify constraints on who can access which class members. Some access specifiers may also control how classes inherit such constraints. Their primary purpose is to separate the interface of a class with its implementation.
A common set of access specifiers that many object-oriented languages support is:
* '''Private''' restricts the access to the class itself. Only methods that are part of the same class can access private members.
* '''Protected''' allows the class itself and all its subclasses to access the member.
* '''Public''' means that all clients can access the member by its name.
Note that although many languages support these access specifiers, the semantics of them may subtly differ in each.
A common usage of access specifiers is to separate the internal data structures of a class from its interface; that is, the internal data structures are private. Public [[accessor method]]s can be used to inspect or alter such private data. The various object-oriented programming languages enforce this to various degrees. For example, the [[Java (programming language)|Java]] language does not allow client code to access the private data of a class at all, whereas in languages like [[Objective-C]] or [[Perl]] client code can do whatever it wants. In [[C++]] language, private methods are visible but not accessible in the interface; however, they are commonly made invisible by explicitly declaring fully abstract classes that represent the interfaces of the class.
Access specifiers do not necessarily control '''visibility''', in that even private members may be visible to client code. In some languages, an inaccessible but visible member may be referred to at run-time (e.g. pointer to it can be returned from member functions), but all attempts to use it by referring to the name of the member from client code will be prevented by the type checker. Object-oriented design uses the access specifiers in conjunction with careful design of public method implementations to enforce class invariants. Access specifiers are intended to protect against accidental use of members by clients, but are not suitable for run-time protection of object's data.
In addition, some languages, such as C++, support a mechanism where a function explicitly declared as ''friend'' of the class may access the members designated as private or protected.
== Associations between classes ==
{{main|Association (object-oriented programming)}}<!--consider moving a bunch of stuff here to this page...-->
In [[object-oriented design]] and in [[Unified_Modelling_Language|UML]], an '''association''' between two classes is a type of a link between the corresponding objects. A (two-way) association between classes A and B describes a relationship between each object of class A and some objects of class B, and vice versa. Associations are often named with a verb, such as "subscribes-to".
An association role type describes the role type of an instance of a class when the instance participates in an association. An association role type is related to each end of the association. A role describes an instance of a class from the point of view of a situation in which the instance participates in the association. Role types are collections of role (instance)s grouped by their similar properties. For example, a "subscriber" role type describes the property common to instances of the class "Person" when they participate in a "subscribes-to" relationship with the class "Magazine". Also, a "Magazine" has the "subscribed magazine" role type when the subscribers subscribe-to it.
Association role multiplicity describes how many instances correspond to each instance of the other class(es) of the association. Common multiplicities are "0..1", "1..1", "1..*" and "0..*", where the "*" specifies any number of instances.
There are some special kinds of associations between classes.
=== Composition ===
{{main|Object composition}}
'''Composition''' between class A and class B describes a "part-of" relationship where instances of class B have shorter [[Object lifetime|lifetime]] than the lifetime of the corresponding instances of the enclosing class. Class B is said to be a part of class A. This is often implemented in programming languages by allocating the data storage of instances of class A to contain a representation of instances of class B.
'''Aggregation''' is a variation of composition that describes that instances of a class are part of instances of the other class, but the constraint on lifetime of the instances is not required. The implementation of aggregation is often via a [[Pointer (computing)|pointer]] or reference to the contained instance. In both cases, method implementations of the enclosing class can invoke methods of the part class. A common example of aggregation is a list class. When a list's lifetime is over, it does not necessarily mean the lifetimes of the objects within the list are also over.
=== Inheritance ===
{{main|Inheritance (computer science)|Superclass (computer science)|Subclass (computer science)}}
Another type of class association is '''inheritance''', which involves '''subclasses''' and '''superclasses''', also known respectively as ''child classes'' (or ''derived classes'') and ''parent classes'' (or ''base classes''). If [car] was a class, then [station wagon] and [mini-van] might be two subclasses. If [Button] is a subclass of [Control], then all buttons are controls. Subclasses usually consist of several kinds of modifications (customizations) to their respective superclasses: addition of new instance variables, addition of new methods and [[overriding]] of existing methods to support the new instance variables.
Conceptually, a superclass should be considered as a common part of its subclasses. This factoring of commonality is one mechanism for providing [[reuse]]. Thus, extending a superclass by modifying the existing class is also likely to narrow its applicability in various situations. In object-oriented design, careful balance between applicability and functionality of superclasses should be considered. Subclassing is different from [[subtyping]] in that subtyping deals with common behaviour whereas subclassing is concerned with common structure.
Some programming languages (for example [[C++]]) allow [[multiple inheritance]] - they allow a child class to have more than one parent class. This technique has been criticized by some for its unnecessary complexity and being difficult to implement efficiently, though some projects have certainly benefited from its use. [[Java (programming language)|Java]], for example has no multiple inheritance, as its designers felt that it would add unnecessary complexity. Java instead allows inheriting from multiple [[pure abstract class]]es (called interfaces in Java).
Sub- and superclasses are considered to exist within a [[hierarchy (object-oriented programming)|hierarchy]] defined by the inheritance relationship. If multiple inheritance is allowed, this hierarchy is a [[directed acyclic graph]] (or DAG for short), otherwise it is a [[tree (graph theory)|tree]]. The hierarchy has classes as nodes and inheritance relationships as links. The levels of this hierarchy are called [[Layer (object-oriented design)|layers]] or [[level of abstraction|levels of abstraction]]. Classes in the same level are more likely to be [[association (object-oriented programming)|associated]] than classes in different levels.
There are two slightly different points of view as to whether subclasses of the same class are required to be disjoint. Sometimes, subclasses of a particular class are considered to be completely disjoint. That is, every instance of a class has exactly one ''most-derived class'', which is a subclass of every class that the instance has. This view does not allow dynamic change of object's class, as objects are assumed to be created with a fixed most-derived class. The basis for not allowing changes to object's class is that the class is a compile-time type, which does not usually change at runtime, and [[Polymorphism in object-oriented programming|polymorphism]] is utilized for any dynamic change to the object's behavior, so this ability is not necessary. And design that does not need to perform changes to object's type will be more robust and easy-to-use from the point of view of the users of the class.
From another point of view, subclasses are not required to be disjoint. Then there is no concept of a most-derived class, and all types in the inheritance hierarchy that are types of the instance are considered to be equally types of the instance. This view is based on a dynamic classification of objects, such that an object may change its class at runtime. Then object's class is considered to be its ''current'' structure, but changes to it are allowed. The basis for allowing changes to object's class is a perceived inconvenience caused by replacing an instance with another instance of a different type, since this would require change of all references to the original instance to be changed to refer to the new instance. When changing the object's class, references to the existing instances do not need to be replaced with references to new instances when the class of the object changes. However, this ability is not readily available in all programming languages. This analysis depends on the proposition that dynamic changes to object structure are common. This may or may not be the case in practice.
==== Languages without inheritance ====
Although class-based languages are commonly assumed to support inheritance, inheritance is not an intrinsic aspect of the concept of classes. There are languages that support classes yet do not support inheritance. Examples are earlier versions of [[Visual Basic]]. These languages, sometimes called "object-based languages", do not provide the structural benefits of statically type-checked interfaces for objects. This is because in object-based languages, it is possible to use and extend data structures and attach methods to them at run-time. This precludes the compiler or interpreter from being able to check the type information specified in the source code as the type is built dynamically and not defined statically. Most of these languages allow for ''instance behaviour'' and complex ''operational polymorphism'' (see [[dynamic dispatch]] and [[Polymorphism (computer science)|polymorphism]]).
== Categories of classes ==
There are many categories of classes depending on modifiers. Note that these categories do not necessarily categorize classes into distinct partitions. For example, while it is impossible to have a class that is both abstract and concrete, a sealed class is implicitly a concrete class, and it may be possible to have an abstract partial class.
=== Concrete classes ===
A '''concrete class''' is a class that can be [[Instantiation (computer science)|instantiated]]. This contrasts with abstract classes as described below.
=== Abstract classes ===
{{main|Abstract type}}
An '''abstract class''', or ''abstract base class'' (ABC), is a class that cannot be instantiated. Such a class is only meaningful if the language supports inheritance. An abstract class is designed ''only'' as a parent class from which child classes may be derived. Abstract classes are often used to represent [[Abstraction (computer science)|abstract]] concepts or entities. The incomplete features of the abstract class are then shared by a group of subclasses which add different variations of the missing pieces.
Abstract classes are superclasses which contain [[abstract method]]s and are defined such that concrete subclasses are to extend them by implementing the methods. The behaviors defined by such a class are "generic" and much of the class will be undefined and unimplemented. Before a class derived from an abstract class can become concrete, i.e. a class that can be instantiated, it must implement particular methods for all the abstract methods of its parent classes.
When specifying an abstract class, the programmer is referring to a class which has elements that are meant to be implemented by inheritance. The abstraction of the class methods to be implemented by the subclasses is meant to simplify [[software development]]. This also enables the programmer to focus on planning and design.
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 (programming language)|Java]], the keyword ''abstract'' is used. In [[C++]], an abstract class is a class having at least one abstract method (a pure virtual function in C++ parlance).
Some languages, notably Java, additionally support a variant of abstract classes called an [[Interface (Java)|interface]]. Such a class can only contain abstract publicly-accessible methods. In this way, they are closely related - but not equivalent - to the abstract concept of [[#Interfaces and methods|interfaces]] described in this article.
=== Sealed classes ===
Some languages also support '''sealed classes'''. A sealed class cannot be used as a base class. For this reason, it cannot also be an abstract class. Sealed classes are primarily used to prevent derivation. They add another level of strictness during compile-time, improve memory usage, and trigger certain optimizations that improve run-time efficiency.
=== Local and inner classes ===
In some languages, classes can be declared in [[Scope (programming)|scopes]] other than the global scope. There are various types of such classes.
One common type is an '''inner class''' or ''nested class'', which is a class defined within another class. Since it involves two classes, this can also be treated as another type of class association. The methods of an inner class can access static methods of the enclosing class(es). An inner class is typically not associated with instances of the enclosing class, i.e. an inner class is not instantiated along with its enclosing class. Depending on language, it may or may not be possible to refer to the class from outside the enclosing class. A related concept is ''inner types'' (a.k.a. ''inner data type'', ''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 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 ===
{{main|Metaclass}}
'''Metaclasses''' are classes whose instances are classes. A metaclass describes a common structure of a collection of classes. A metaclass can implement a [[design pattern (computer science)|design pattern]] or describe a shorthand for particular kinds of classes. Metaclasses are often used to describe [[framework]]s.
In some languages such as [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]], [[Java (programming language)|Java]], and [[Smalltalk]], a class is also an object; thus each class is an instance of the unique metaclass, which is built in the language. For example, in [[Objective-C]], each object and class is an instance of NSObject. The [[Common Lisp]] [[Common Lisp Object System|Object System]] (CLOS) provides [[Metaobject|metaobject protocols]] (MOPs) to implement those classes and metaclasses.
=== Partial classes ===
{{main|Partial class}}
'''Partial classes''' are classes that can be split over multiple definitions (typically over multiple files), making it easier to deal with large quantities of code. At [[Compiler|compile]] time the partial classes are grouped together, thus logically make no difference to the output. An example of the use of partial classes may be the separation of user interface logic and processing logic. A primary benefit of partial classes is allowing different programmers to work on different parts of the same class at the same time. They also make automatically generated code easier to interpret, as it is separated from other code into a partial class.
Partial classes have been around in [[Smalltalk]] under the name of ''Class Extensions'' for considerable time. With the arrival of the [[.NET Framework|.NET framework 2]], [[Microsoft]] introduced partial classes, supported in both [[C Sharp (programming language)|C#]] 2.0 and [[Visual Basic .NET|Visual Basic 2005]].
== Non-class-based object-oriented programming ==
{{see also|Object-based}}
To the surprise of some familiar with the use of classes, classes are not the only way to approach object-oriented programming. Another common approach is [[prototype-based programming]]. Languages that support non-class-based programming are usually designed with the motive to address the problem of tight-coupling between implementations and interfaces due to the use of classes. For example, the [[Self programming language|Self]] language, a prototype-based language, was designed to show that the role of a class can be substituted by using an extant object which serves as a prototype to a new object, and the resulting language is as expressive as [[Smalltalk]] with more generality in creating objects.
== Examples ==
=== C++ ===
==== Example 1 ====
<source lang="cpp">
#include <iostream>
#include <string>
using namespace std;
class Hello
{
string what;
public:
Hello(const string& s)
: what(s)
{
}
void say()
{
cout << "Hello " << what << "!" << endl;
}
};
int main( int argc, char** argv )
{
Hello hello_world("world");
hello_world.say();
return 0;
}
</source>
This example shows how to define a [[C++]] class named "<code>Hello</code>". It has a private string attribute named "<code>what</code>", and a public method named "<code>say</code>".
==== Example 2 ====
<source lang="cpp">
class MyAbstractClass
{
public:
virtual void MyVirtualMethod() = 0;
};
class MyConcreteClass : public MyAbstractClass
{
public:
void MyVirtualMethod()
{
//do something
}
};
</source>
An object of class MyAbstractClass cannot be created because the function MyVirtualMethod has not been defined (the =0 is C++ syntax for a pure virtual function, a function that must be part of any derived concrete class but is not defined in the abstract base class. The MyConcreteClass class is a concrete class because its functions (in this case, only one function) have been declared and implemented.
==== Example 3 ====
<source lang="cpp">
#include <string>
#include <iostream>
using namespace std;
class InetMessage
{
string m_subject, m_to, m_from;
public:
InetMessage (const string& subject,
const string& to,
const string& from) : m_subject(subject), m_to(to), m_from(from) { }
string subject () const { return m_subject; }
string to () const { return m_to; }
string from () const { return m_from; }
virtual void printTo(ostream &out)
{
out << "Subject: " << m_subject << endl;
out << "From: " << m_from << endl;
out << "To: " << m_to << endl;
}
};
</source>
=== Java ===
==== Example 1 ====
<source lang="java">
public class Example1
{
// This is a Java class, it automatically extends the class Object
public static void main (String args[])
{
System.out.println("Hello world!");
}
}
</source>
This example shows a simple [[hello world program]].
==== Example 2 ====
<source lang="java">
public class Example2 extends Example1
{
// This is a class that extends the class created in Example 1.
protected int data;
public Example2()
{
// This is a constructor for the class. It does not have a return type.
data = 1;
}
public int getData()
{
return data;
}
public void setData(int d)
{
data = d;
}
}
</source>
This example shows a class that has a defined constructor, one member data, an accessor method (getData) and a Modifier method (setData) for that member data. It extends the previous example's class. Note that in Java all classes automatically extend the class Object. This allows you to write generic code to deal with objects of any type.
=== Visual Basic .NET ===
==== Example 1====
<source lang="vbnet">
Class Hello
Private what as String
Sub New( ByVal s as String )
what = s
End Sub
Sub Say()
MessageBox.Show("Hello " & what )
End Sub
End Class
Sub Main()
Dim h as new Hello( "Foobar" )
h.Say()
End Sub
</source>
This example is a port of the C++ example above. It demonstrates how to make a class named Hello with a private property named what. It also demonstrates the proper use of a constructor, and has a public method named Say. It also demonstrates how to instantiate the class and call the Say method.
===PHP===
====Example 1====
<source lang="php">
<?php
class A {
public function foo() {
if (isset($this)) {
echo '$this is defined (';
echo get_class($this);
echo ")\n";
} else {
echo "\$this is not defined.\n";
}
}
}
?>
</source>
====Example 2====
<source lang="PHP">
<?php
class DateObject
{
public function getTime()
{
/** For E_STRICT mode:
*
* date_default_timezone_set('CET');
*/
return(time());
}
public function getDate()
{
return(date('jS F, Y', $this->getTime());
}
}
?>
</source>
===C#===
====Example 1====
<source lang="csharp">
using System;
public class Program
{
public static void Main(string[] args)
{
System.Console.WriteLine("Hello world!");
}
}
</source>
This example demonstrates a traditional "Hello world!" example in Microsoft's C# language. The Program class contains a single static method, Main(), which calls System.Console.WriteLine to print text onto the console.
====Example 2====
<source lang="csharp">
using System;
public class Hello
{
private string what;
public Hello(string s)
{
what = s;
}
public void Say()
{
Console.WriteLine("Hello " + what + "!");
}
}
public class Program
{
public static void Main(string[] args)
{
Hello helloWorld = new Hello("world");
helloWorld.Say(); // prints "Hello world!" onto the console
}
}
</source>
This is another port of the above C++ example. A class called Hello is created with a constructor that
takes a string parameter. When the Say() method is called, the instance of Hello will print "Hello {what}!"
onto the console. Notice that the Main() method (the entry point) is actually contained in a class itself.
===ActionScript===
====Example 1====
<source lang="actionscript">
class Cart {
private var cart:Array;
public function Cart() {
this.cart = new Array();
}
public function addItem(id:Number, name:String):Void {
this.cart.push([id, name]);
}
public function removeItemById(id:Number):Void {
var ln:Number = this.cart.length;
for (var i:Number = 0; i<ln; i++) {
var curr:Array = this.cart[i];
if (curr[0] == id) this.cart.splice(i, 1);
}
}
public function removeItemByName(name:String):Void {
var ln:Number = this.cart.length;
for (var i:Number = 0; i<ln; i++) {
var curr:Array = this.cart[i];
if (curr[1] == name) this.cart.splice(i, 1 );
}
}
}
</source>
===Ruby===
====Example 1====
<source lang="Ruby">
class Hello
def self.hello
string = "Hello world!"
return string
end
end
</source>
A Ruby class "Hello", with one method "hello". This method returns the variable "string", which is set to "Hello world!".
===Python===
====Example 1====
<source lang="Python">
class Hello:
def __init__(self):
print "Hello world!"
</source>
A Python class "Hello", which prints "Hello World!" on creation.
==See also==
* [[Hierarchy (object-oriented programming)|Hierarchy]]
* [[Class diagram]] (UML)
* [[Class-based programming]]
==Literature==
* Meyer, B.: "Object-oriented software construction", 2nd edition, Prentice Hall, 1997, ISBN 0-13-629155-4
* Rumbaugh et al.: "Object-oriented modeling and design", Prentice Hall, 1991, ISBN 0-13-630054-5
* [http://www.open-std.org/jtc1/sc22/wg21/ ISO/IEC 14882:2003 Programming Language C++, International standard]
* [http://lucacardelli.name/TheoryOfObjects.html Abadi; Cardelli: A Theory of Objects]
[[Category:Object-oriented programming]]
[[Category:Programming constructs]]
[[af:Klasse]]
[[be-x-old:Кляса (праграмаваньне)]]
[[bs:Računarska klasa]]
[[ca:Classe (informàtica)]]
[[cs:Třída (programování)]]
[[da:Klasse (datalogi)]]
[[de:Klasse (objektorientierte Programmierung)]]
[[es:Clase (informática)]]
[[eo:Klaso (objektema programado)]]
[[fa:کلاس (برنامهنویسی)]]
[[fr:Classe (informatique)]]
[[is:Klasi (forritun)]]
[[it:Classe (informatica)]]
[[he:מחלקה (תכנות)]]
[[lt:Klasė (programavimas)]]
[[nl:Klasse (informatica)]]
[[ja:クラス (コンピュータ)]]
[[pl:Klasa (programowanie obiektowe)]]
[[pt:Classe (programação)]]
[[ru:Класс (программирование)]]
[[simple:Class (programming)]]
[[sk:Trieda (programovanie)]]
[[su:Class (élmu komputer)]]
[[fi:Kapselointi]]
[[sv:Klass (programmering)]]
[[ta:வகுப்பு (கணினியியல்)]]
[[th:คลาส]]
[[vi:Lớp (khoa học máy tính)]]
[[uk:Клас (програмування)]]
[[zh:类 (计算机科学)]]