Object Orientation

If we want to model in an object-oriented style, we must first clarify what object orientation means.
The introduction of object orientation dates back to the 1960s when the simulation language SIMULA was presented, building on a paradigm that was as natural to humans as possible to describe the world.

The object-oriented approach corresponds to the way we look at the real world; we see it as a society of autonomous individuals, referred to as objects, which take a fixed place in this society and must thereby fulfill predefined obligations.

There is not only one single definition for object orientation. However, there is a general consensus about the properties that characterize object orientation. Naturally, objects play a central role in object-oriented approaches.

Viewed simply, objects are elements in a system whose data and operations are described. Objects interact and communicate with one another.

                              Classes

In many object-oriented approaches, it is possible to define classes that describe the attributes and the behavior of a set of objects (the instances of a class) abstractly and thus group common features of objects.

For example, people have

• a name, 
• an address, and a 
• social security number(SSN).

Courses have

• a unique identifier, 
• a title, and 
• a description.

Lecture halls have

• a name as well as 
• a location, etc.

A class also defines a set of permitted operations that can be applied to the instances of the class.

For example, you can reserve a lecture hall for a certain date, a student can register for an exam, etc.

In this way, classes describe the behavior of objects.

                            Objects

The instances of a class are referred to as its objects.
For example, lh1,the Lecture Hall 1 of the Vienna University of Technology, is a concrete instance of the class LectureHall.

In particular, an object is distinguished by the fact that it has its own identity, that is, different instances of a class can be uniquely identified. 

For example, the beamer in Lecture Hall 1 is a different object to the beamer in Lecture Hall 2, even if the devices are of the same type.

Here we refer to identical devices but not the same device. 

The situation for concrete values of data types is different: the number 1, which is a concrete value of the data type Integer, does not have a distinguishable identity.

An object always has a certain state. A state is expressed by the values of its attributes. 

For example, a lecture hall can have the state

• occupied or 
• free.

An object also displays behavior.

The behavior of an object is described by the set of its operations. Operations are triggered by sending a message.

                          Encapsulation

Encapsulation is the protection against unauthorized access to the internal state of an object via a uniquely defined interface.

Different levels of visibility of the interfaces help to define different access authorizations. 

Java, for example, has the explicit visibility markers 

• public,
• private, and 
• protected,

which respectively permit access for

• all,
• only within the object, and 
• only for members of the same class, its subclasses, and of the same package.

                             Messages

Objects communicate with one another through messages.

1. A message to an object represents a request to execute an operation. 
2. The object itself decides whether and how to execute this operation. 
3. The operation is only executed if the sender is authorized to call the operation—this can be regulated in the form of visibilities (see Encapsulation)—and a suitable implementation is available.

In many object-oriented programming and modeling languages the concept of overloading is supported. This enables an operation to be defined differently for different types of parameters. 
For example, the operator + realizes different behavior depending on whether it is used to add up integers (e.g., 1 + 1= 2) or to concatenate character strings (e.g., “a” + “b” = “ab”).


                           Inheritance

The concept of inheritance is a mechanism for deriving new classes
from existing classes. A subclass derived from an existing class (= superclass) inherits all visible attributes and operations (specification and implementation) of the superclass.

A subclass can:

• Define new attributes and/or operations
• Overwrite the implementation of inherited operations
• Add its own code to inherited operations

Inheritance enables extensible classes and as a consequence, the creation of class hierarchies as the basis for object-oriented system development.
A class hierarchy consists of classes with similar properties,
for example, Person ← Employee ← Professor ← ... where
A ← B means that B is a subclass of A.

When used correctly, inheritance offers many advantages:

1. reuse of program or model parts (thus avoiding redundancy and errors), 
2. consistent definition of interfaces, 
3. use as a modeling aid through a natural categorization of the occurring elements, and 
4. support for incremental development, i.e., a step-by-step refinement of general concepts to specific concepts.

                           Polymorphism

In general terms, polymorphism is the ability to adopt different forms.

During the execution of a program, a polymorphic attribute can have references to objects from different classes. 

When this attribute is declared, a type (e.g., class Person) is assigned statically at compile time.
At runtime, this attribute can also be bound dynamically to a sub-
type (e.g., subclass Employee or subclass Student).

A polymorphic operation can be executed on objects from different
classes and have different semantics in each case. This scenario can be implemented in many ways:

1.  via parametric polymorphism, better known as genericity—here, type parameters are used. In Java for example, the concrete classes are transferred to the operations as arguments;
2. via inclusion polymorphism—operations can be applied to classes and to their direct and indirect subclasses; 
3. via overloading of operations; and 
4. via coercion, that is, the conversion of types.

The first two methods above are known as universal polymorphism; the other two methods are referred to as ad hoc polymorphism.

Resources

.