object oriented programing

from Wikipedia, the free encyclopedia

The object-oriented programming (short OOP ) is a on the concept of object orientation based programming paradigm . The basic idea is to align the architecture of a software with the basic structures of that area of ​​reality that affects the given application. A model of these structures is set up in the design phase . It contains information about the occurring objects and their abstractions, their types . Implementing this mindset requires introducing various concepts, particularly classes , inheritance , polymorphism, and late binding.

definition

The definition of what object-oriented programming is and what it is essentially about varies and is also subject to change.

Alan Kay , the inventor of the programming language Smalltalk and the term "object oriented", defined it in the context of Smalltalk as follows:

"1. Everything is an object, 2. Objects communicate by sending and receiving messages (in terms of objects), 3. Objects have their own memory (in terms of objects), 4. Every object is an instance of a class (which must be an object), 5. The class holds the shared behavior for its instances (in the form of objects in a program list), 6. To eval a program list, control is passed to the first object and the remainder is treated as its message ”

"1. Everything is an object, 2. Objects communicate by sending and receiving messages (which consist of objects), 3. Objects have their own memory (structured as objects), 4. Each object is an instance of a class (which can be an object must), 5. The class contains the behavior of all its instances (in the form of objects in a program list), 6. In order to execute a program list, execution control is given to the first object and the remaining part is treated as its message "

- Alan Kay : The Early History of Smalltalk (1993)

Alan Kay later expressed his dissatisfaction with the term "object orientation" he had chosen because, in his opinion , it would neglect the core aspect of messaging .

In 2003 Alan Kay gave the following definition of object-oriented programming:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

"For me, OOP only means messaging, local maintenance and protection and hiding of the process status as well as the latest possible binding of all things."

- Alan Kay : Answer to an inquiry, 2003

The ISO / IEC-2382-15 standard from 1999, on the other hand, defines the term object-oriented as follows:

"Pertaining to a technique or a programming language that supports objects, classes, and inheritance."

"Refers to a technology or programming language that supports objects, classes and inheritance."

- ISO / IEC 2382-15

The ISO definition is now generally considered to be too simplistic, since classless object-oriented languages ​​also exist and inheritance is now less important than it was in the 1990s.

Concepts

Compared to other programming methods, object-oriented programming uses new, different terms.

The individual building blocks that make up an object-oriented program while it is being processed are called objects. The objects are usually developed on the basis of the following concepts:

abstraction
Every 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 (see abstract data type ). Such abstractions are either classes (in class-based object orientation) or prototypes (in prototype-based programming).
class
The data structure of an object is determined by the attributes (including properties ) of its class definition. The behavior of the object is determined by the methods of the class. Classes can be derived from other classes ( inheritance ). The class inherits the data structure ( attributes ) and the methods from the inheriting class ( base class ).
prototype
Objects are created by cloning existing objects and can serve as prototypes for other objects and thus make their own methods available for reuse, with the new objects only having to define the differences to their prototype. Changes to the prototype also take effect dynamically on the objects derived from it.
Data encapsulation
In programming, data encapsulation is the hiding of implementation details. The internal data structure cannot be accessed directly, but only via defined interfaces. Objects cannot read or change the internal state of other objects in unexpected ways. An object has an interface that determines how the object can be interacted with. This prevents invariants of the program from being bypassed .
Feedback
Different objects communicate via a message-response mechanism, which leads to changes in the objects and generates new message calls. The coupling stands for this as an index for the degree of feedback.
Persistence
Object variables exist as long as the objects exist and do not "expire" after a method has been processed.
Polymorphism
Ability of an identifier to accept different data types depending on how it is used. Different objects can react differently to the same message. If the type of response to the message is not resolved until runtime , this is also called a late binding .
Inheritance
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.

Objects

object
An element that has functions, methods, procedures, an internal state, or several of these things.
entity
An object that has an identity that is immutable. For example, a person can change their address, phone number, or name without becoming a different person. So a person is an entity.
Value object
An object that is defined by its value. A phone number that changes is therefore a different phone number. Similarly, an address in which only the house number changes is another address, even if all other data remains the same. Thus, a telephone number and an address do not represent an entity, but a value object.
property
Part of the state of an object. This can be an entity or a value object.
service
An object that implements behavior (e.g. business logic) in the form of procedures, functions or methods. The service uses entities or value objects for this.
procedure
Changes the state of an object without supplying a return value. A procedure can accept other objects as parameters.
function
Assigns a specific return value to a given input. A function is particularly characterized by the fact that it does not change the state of an object.
method
Changes the state of an object and also provides a return value. A method can accept other objects as parameters.
module
A combined group of objects.

Classes

Most programming languages ​​use the concept of the class for better management of similar objects. Classes are templates from which objects called instances are generated at runtime. In the program, not individual objects but a class of similar objects are defined. If there are no classes in the selected programming language or if these are explicitly suppressed, the distinction is often also called object-based programming .

You can think of the creation of objects from a class as the production of cars from the construction plan of a certain type of vehicle. Classes are the construction plans for objects.

The class corresponds roughly to a complex data type as in procedural programming , but goes beyond that: It not only defines the data types that make up the objects created with the aid of the classes, it also defines the algorithms that operate on this data. While individual objects interact with each other during the runtime of a program, the basic pattern of this interaction is determined by the definition of the individual classes.

example

The “car” class specifies that the car has four tires of a certain size, five colored doors, an engine with a certain output and five seats with selectable covers.

  1. The "Auto1" object has four tires with a diameter of 19 inches and a width of 255 mm, five red doors, a 150 kW engine and five leather seats.
  2. The "Auto2" object has four tires with a diameter of 19 inches and a width of 255 mm, five red doors, a motor with 150 kW and five leather seats.
  3. Another object “Auto3” has four tires with a diameter of 16 inches and a width of 205 mm, five blue doors, a motor with 90 kW and five seats with textile covers.

There are three objects; two of them have the same attributes. However, all three are instances (instances) of the “Auto” class.

Methods in classes

The algorithms assigned to a class of objects are also known as methods .

The term method is often used synonymously with the terms function or procedure from other programming languages. However, the function or procedure should be viewed more as an implementation of a method. In everyday usage one also says "Object  A calls method  m of object  B. "

Methods for encapsulation play a special role , especially the access functions . Special methods for creating and destroying objects are called constructors or destructors .

Methods can receive parameters that have to be passed when called and have a return value that they return to the caller at the end. For example, the method add the parameters number 1 and number 2 and returns the sum of the numbers as the return value.

In many object-oriented programming languages, it is possible to define which objects are allowed to call a particular method. So access levels, a distinction is usually between four and is already available at compile time to be tested.

  1. Public ( public ) methods may be called by all classes.
  2. Protected ( protected ) methods may be used by classes in the same package and derived classes are called.
  3. Methods at package level can only be called by classes that are in the same package - this access level is only available for programming languages ​​that know packages or namespaces .
  4. Private methods can only be called by other methods of the same class.

Analogous to these four access levels, four visibilities for operations are defined in the Unified Modeling Language (UML) .

Attributes

Objects (windows, buttons, scroll bars, menus, ...) have different properties (color, size, alignment, ...). These properties of an object are called attributes .

Polymorphism

Under certain conditions, algorithms that operate on the interfaces of a certain object type can also work together with objects of classes derived therefrom.

If this is done in such a way that methods overwritten by inheritance are executed instead of the methods of the inheriting class, this is called polymorphism. Polymorphism thus provides a way of giving a name to an action performed by similar objects, with each class implementing the action in a manner appropriate for the object.

This technique, known as overriding , does not implement a universal polymorphism , but only the so-called ad hoc polymorphism.

terminology

The terms in object-oriented programming sometimes have different names. The following terms are used synonymously:

Designations in object-oriented programming
German term Alternatives English
Derived class Child class, subclass, subclass child class, subclass
attribute Object variable, instance variable, data element, property member, property
Base class Parent class, upper class, super class parent class, superclass
Instance Copy, object instance
method Member function method
Static method Class function, metafunction static method

Object-oriented programming languages

Object-oriented programming languages support program structuring with a special data type - the object that enables object orientation. The purely object-oriented languages ​​such as Smalltalk follow the principle: “Everything is an object.” Elementary types such as integers are also represented by objects - even classes are objects here, which in turn are examples of metaclasses. The common object-oriented programming languages, including C # , C ++ and Java , do not all handle the object principle so strictly. With them, elementary data types are not fully-fledged objects because they have to do without methods and structures. They also allow the developer to decide how much he adheres to the encapsulation of object-internal data.

The first known object-oriented programming language was Simula -67. Later on, the principles of encapsulation in a class hierarchy were further expanded in Smalltalk . With the ANSI /X3.226-1994 standard, Common Lisp / CLOS became the first standardized object-oriented programming language and with ISO 8652: 1995 Ada 95 was defined as the first object-oriented programming language standardized according to the international ISO standard.

Common modern programming languages ​​(e.g. Python ) support both OOP and the procedural approach that prevailed in the classic programming languages ​​of the 1970s and 1980s such as Pascal , Fortran or C. In contrast, Smalltalk, the oldest OOP language that is still significant today, relies on uncompromising object orientation and thus had a strong influence on the development of popular OOP languages ​​without achieving their distribution itself, because no inexpensive, generally available implementation was offered. Even if the breakthrough of OOP did not take place until the 1990s, object-oriented programming was developed as early as the late 1960s with Simula-67 as a solution for the modularization and reusability of code.

techniques

Object concepts in programming languages

In some object-oriented programming languages ​​such as Go , NewtonScript and Self there is no need to declare classes. Instead, new objects are derived from existing objects, the so-called prototypes . The attributes and methods of the prototype are always used if they have not been explicitly overwritten in the derived object. This is particularly advantageous for developing smaller programs, as it is simpler and saves time.

In some programming languages, for example in Objective-C , there is a specific object ( class object ) for each class that represents the class at runtime; this class object is then also responsible for creating objects of the class and calling the correct method.

Classes are usually grouped together in the form of class libraries , which are often organized thematically. For example, users of an object-oriented programming language can acquire class libraries that enable access to databases, for example.

Drafting of object concepts

The parts of speech in a linguistic problem description can provide helpful hints for designing object-based modeling (so-called verb-noun method ). Objects and classes are usually described linguistically by nouns , with proper names referring to objects and appellatives such as house and animal refer to classes. Verbs usually stand for methods, whereby adverbs and nouns can provide additional characterizations of the methods. The values ​​of object attributes often correspond to numerals or adjectives .

There are meanwhile also refinements of object-oriented programming through methods such as design patterns , design by contract and graphic modeling languages such as the Unified Modeling Language .

Aspect-oriented programming , in which aspects of properties and dependencies are described, is becoming increasingly important . The first approaches can be seen, for example, in Java with JEE or abstract data management via persistence layers.

Limits of OOP

The object-oriented paradigm has advantages and disadvantages depending on the field of application in software technology or the specific problem.

Mapping of problems to OOP techniques

The OOP, like other programming paradigms, can be used to map problems from the real world. The circle-ellipse problem is a typical example of problems that evade skillful modeling with OOP techniques .

Object-oriented programming languages ​​and natural languages

Object-oriented programming languages ​​can also be compared with natural languages ​​from a linguistic point of view. OO programming languages ​​focus on objects, which are verbal nouns . The verbs ( actions ) are secondary, firmly bound to nouns ( encapsulated ) and in general cannot stand on their own. In natural languages ​​and z. B. procedural languages ​​verbs exist independently and independently of the nouns (data), z. B. as imperative and function . It can be argued that in some use cases this linguistic limitation leads to unnecessarily complicated descriptions of real-world problems with object-oriented languages.

OOP and control flow

Frequently mentioned advantages of the OOP paradigm are improved maintainability and reusability of the static source code. For this purpose, however, the control flows and the dynamic runtime behavior are generally subordinate to the data / objects, abstracted and encapsulated. The control flows are no longer mapped directly in the code structures in a transparent manner for the developer (as is the case with procedural languages , for example ); implementation in this regard is left to the compiler. Hardware-related languages ​​such as procedural C or assembler map the real control flow and runtime behavior more transparently. However, with the growing importance of parallel hardware and concurrent code , better control and developer transparency of the increasingly complex control flows are becoming increasingly important - something that is difficult to achieve with OOP.

OOP and relational databases

A frequently mentioned area in which OOP techniques are considered inadequate is the connection of relational databases . OOP objects cannot be mapped directly in all aspects with relational databases. Conversely, the strengths and capabilities of relational databases cannot be fully exploited via OOP. The need to build a bridge between these two conceptual worlds is known as the object-relational impedance mismatch . There are many approaches to this, for example the frequently used object-relational mapping , but no generally applicable solution without one or the other disadvantage.

Runtime behavior and energy efficiency

The effectiveness of the runtime behavior of applications based on OOP techniques has always been a controversial issue. Alexander Chatzigeorgiou from the University of Macedonia compared the runtime effectiveness and the energy efficiency of typical algorithms ( Gauss-Jordan algorithm , Trapezoidal integration and QuickSort ) of procedural approaches and OOP techniques, implemented as C and C ++ software. On the ARM processor used , the average runtime effectiveness for three algorithms was 48.41% better with the procedural C algorithm variants. The average power consumption of the C ++ variants compared to the C variants was also 95.34% higher. Such differences are significant for applications on mobile devices, such as cell phones or MP3 players with limited performance and energy storage capacity, but such algorithms usually only make up a fraction of the applications. The reason for the difference in effectiveness and energy efficiency is given in the article as general abstraction performance losses and the significantly larger number of accesses to the main memory using OOP techniques.

criticism

Modularization and other principles not fully developed

In 1996, Luca Cardelli examined the efficiency of OOP approaches for the DEC Systems Research Center in the article Bad Engineering Properties of Object-Oriented Languages with the metrics program execution speed ( economy of execution ), compilation speed ( economy of compilation ), development efficiency for large and small teams ( economy of small-scale development and economy of large-scale development ) and the elegance of the language range itself ( economy of language features ). He came to the conclusion that object-oriented language design still had to learn a lot from procedural language design, especially in the areas of good modularization, data abstraction and polymorphism, in order to meet the high expectations.

No increase in productivity compared to procedural approaches

A study by Potok et al. from 1999 showed no significant productivity differences between OOP and procedural approaches.

The authors define “productivity” in terms of “developed / changed program lines per unit of time” and examine in particular the influence of code reuse on this metric. They point out that focusing on code reuse may not do object-oriented programming justice because it could have positive effects on productivity in other ways, such as simpler design.

The authors cite several reasons why the results of their study might be biased:

  • It could be that software declared as "object-oriented" was actually developed procedurally.
  • They only analyzed two generations of object-oriented software, which they said could not be enough.
  • It could be that the qualifications of the different development teams were different. In particular, it would be possible that the object-oriented software was developed by less qualified teams.

The authors take the view that these points do not apply.

See also

literature

Web links

Individual evidence

  1. ^ Alan Kay : The Early History of Smalltalk ( en ) In: The second ACM SIGPLAN conference on History of programming languages . ACM. P. 78. March 1, 1993. doi : 10.1145 / 155360.155364 . Retrieved on June 4, 2012. ( PDF ( Memento of the original from February 5, 2012 in the Internet Archive ) Info: The archive link has been inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this note. ) @1@ 2Template: Webachiv / IABot / www.smalltalk.org
  2. ^ Alan Kay On Messaging . October 10, 1998. Retrieved June 4, 2012: “[…] Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" [...] "
  3. ↑ Stefan Ram: Dr. Alan Kay on the Meaning of Object-Oriented Programming ( English ) fu-berlin.de. July 23, 2003. Retrieved June 4, 2012.
  4. ↑ ISO 2382-15: 1998 Information technology - Vocabulary - Part 15: Programming languages; Revision of first edition ISO 2382-15: 1985 ( English ) iso.org. 1999. Retrieved June 4, 2012.
  5. ↑ a b c d Debasish Ghosh: Functional and Reactive Domain Modeling . Manning, 2016, ISBN 978-1-61729-224-8 (English, 325 pages).
  6. ↑ David J. Barnes, Michael Kölling: Learn Java with BlueJ: An Introduction to Object-Oriented Programming . Munich 2009, ISBN 978-3-86894-001-5 , pp. 496 .
  7. ^ Russell J. Abbott: Program design by informal English descriptions . In: Communications of the ACM . 26, 1983, pp. 882-894. doi : 10.1145 / 182.358441 .
  8. ↑ Jörg Bewersdorff : Object-oriented programming with JavaScript: direct start for beginners . 2nd Edition. Wiesbaden 2018, ISBN 978-3-658-21076-2 , pp. 30-33 , doi : 10.1007 / 978-3-658-21077-9_4 .
  9. ↑ Steve Yegge: Execution in the Kingdom of Nouns . steve-yegge.blogspot.com. March 30, 2006. Retrieved July 3, 2010.
  10. ↑ Timothy Borończyk: What's Wrong with OOP . zaemis.blogspot.com. June 11, 2009. Retrieved July 3, 2010.
  11. ^ Scott Ambler: A Realistic Look at Object-Oriented Reuse . drdobbs.com. January 1, 1998. Retrieved July 4, 2010.
  12. ^ Asaf Shelly: Flaws of Object Oriented Modeling . Intel® Software Network. August 22, 2008. Retrieved July 4, 2010.
  13. ↑ Justin James: Multithreading is a verb not a noun . techrepublic.com. October 1, 2007. Retrieved July 4, 2010.
  14. ↑ Asaf Shelly: HOW TO: Multicore Programming (Multiprocessing) Visual C ++ Class Design Guidelines, Member Functions . support.microsoft.com. August 22, 2008. Retrieved July 4, 2010.
  15. ↑ Ted Neward: The Vietnam of Computer Science . Interoperability happens. June 26, 2006. Archived from the original on July 4, 2006. Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved June 2, 2010. @1@ 2Template: Webachiv / IABot / blogs.tedneward.com
  16. ↑ Alexander Chatzigeorgiou: Performance and power evaluation of C ++ object-oriented programming in embedded processors . In: Information and Software Technology . 45, No. 4, 2003, pp. 195-201. ISSN  0950-5849 . doi : 10.1016 / S0950-5849 (02) 00205-7 .
  17. ^ Luca Cardelli: Bad Engineering Properties of Object-Oriented Languages . In: ACM (Ed.): ACM Comput. Surv . 28, 1996, p. 150. ISSN  0360-0300 . doi : 10.1145 / 242224.242415 . Retrieved April 21, 2010.
  18. ↑ Thomas Potok, Mladen Vouk, Andy Rindos: Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment . In: Software - Practice and Experience . 29, No. 10, 1999, pp. 833-847. Retrieved April 21, 2010.