Object orientation
Under object orientation (short OO ) is understood in the development of software a perspective on complex systems , in which a system through the interaction of cooperating objects is described. The term object is blurred; The only important thing about an object is that it has certain attributes ( properties ) and methodsare assigned and that it is able to receive messages from or to send messages to other objects. An object does not have to be representational. It is crucial that a meaningful and generally customary assignment is possible for the respective object term. This is supplemented by the concept of the class , in which objects are grouped based on similar properties. An object is defined in the program code as an instance or incarnation of a class.
Object orientation is mainly used in object-oriented programming to reduce the complexity of the resulting programs. However, the term also exists for other phases of software development prior to programming, such as object-oriented analysis and object-oriented design ( synonym object-oriented design ) of software. The concepts of object orientation can also be applied to persistent data. One speaks of object databases .
In programming languages that are not set up for object orientation, data and program parts are deliberately separated; they have to be declared separately. In comparison to this, the object-oriented programming paradigm claims to combine data and associated program parts into a unit and thus better simulate organizational structures from the real world.
Almost all high-level programming languages support object-oriented programming.
Inheritance
As a rule, the concept of inheritance can be found in object-oriented approaches , in which properties and methods can be hierarchically exchanged or supplemented between classes.
Inheritance means, in simplified terms, that a derived class also has the methods and attributes of the base class , ie “inherits”. Thus the derived class can also access it. New types of objects can be defined on the basis of existing object definitions. New components can be added or existing ones can be superimposed.
The concept of multiple inheritance , which allows the non-hierarchical exchange of properties, is less common .
If inheritance is not permitted, the distinction is often referred to as object-based .
Polymorphism
The concept of polymorphism (diversity) has the effect that properties or methods of a class of objects can be referenced without having to know the specific expression in an addressed object.
In addition, with aggregation, there is the distinction between the whole and its parts. Each object in the system can be viewed as an abstract model of an actor who can complete orders, report and change its status and communicate with the other objects in the system without having to disclose how these capabilities are implemented (cf. abstract data type , ADT ).
Encapsulation
The data encapsulation allows the internal implementation to be sealed off from direct external access. This may only be done via an explicitly defined interface in order to make it independent of the implementation details.
Simplified view of the real world
A classification is generally a restriction / simplification of the real world in a very special context. So there will never be "the" classification. It always depends on the goal that is to be achieved with the classification. For example, while a class “car” in the context of a car manufacturer may have attributes such as wheels and color and will know its components (in the form of attributes or relationships), a class “car” in the context of a dealer has attributes such as product number, price, consumption and date of first registration. In the context of a registration office, there will be attributes such as license plate number, maximum permissible weight and the holder.
In addition, it is not always possible to clearly and objectively decide whether a property should be represented in the form of an attribute of the object or in the form of a relationship to another object. For example, the “color” property of the car from the example above can be modeled either as a text attribute (to display a textual color description, such as a RAL or DIN color number ) or as a relationship to the “color” class. The latter is useful if special properties are to be modeled for the color class. In addition, it may be necessary that the color property is not modeled for the entire car, but for the individual components (for example because the colors of the bumper, mirrors and bonnet may not have to be identical to the body color).
This last aspect in particular often depends on the point in time at which the model is modeled: While the manufacturer today associates the entire car with a single color, tomorrow he may actually want to give each component its own color. The simplification that is sufficient today to solve a problem may not be enough tomorrow.