Objektorientierte Programmierung
Objektorientierte Programmiersprachen
[Bearbeiten]Objektorientierte Programmiersprachen unterstützen die Programmstrukturierung mit einem speziellen Datentyp – dem Objekt, der die Objektorientierung ermöglicht.
Reine objektorientierte Sprachen
[Bearbeiten]Die rein objektorientierten Sprachen, wie Smalltalk, folgen dem Prinzip: „Alles ist ein Objekt.“ Auch elementare Typen wie Ganzzahlen werden dabei durch Objekte repräsentiert – selbst Klassen sind hier Objekte, die wiederum Exemplare von Metaklassen sind.
Elementare Datentypen in C, Java
[Bearbeiten]Die verbreiteten objektorientierten Programmiersprachen, unter anderem C#, C++ und Java, handhaben das Objektprinzip nicht alle so streng gefasst. Bei ihnen sind z.B. elementare Datentypen keine vollwertigen Objekte, da sie auf Methoden und Struktur verzichten müssen.
Kapselung von Daten
[Bearbeiten]Objektorientierte Programmiersprachen stellen dem Entwickler auch frei, wie stark man die Kapselung objektinterner Daten einhält. Bei einer strengen Kapselung kann man auf objektinterne Daten nur über Methoden zugreifen, um diese auszulesen oder die objektinternen Daten zu verändern.
Beispiel - Kapselung
[Bearbeiten]Die Methoden haben dann ggf. die Aufgabe fehlerhafte oder nicht zulässige Zuweisungen abzuprüfen (z.B. der Attribute 'name' eines Objekts 'x' kann man z.B. ungekapselt direkt über
x.name="Maria"
zuweisen, wobei z.B. auch x.name="12345" formal als Stringzuweisung zulässig wäre. Eine Methode
x.setName(pName)
als Parameter den neuen Namen 'pName' erhalten. Bei einem konkreten Methodenaufruf
x.setName("Maria")
würde auch die gekapselte Variable name analog zu x.name="Maria" auf "Maria" gesetzt, während bei
x.setName("12345")
der Name "12345" als unzulässig bewertet wird und eine Zuweisung analog zu x.name="12345" nicht erfolgt und die bisherige Belegung von 'x.name' unverändert bleibt.
Geschichte objektorientierte Sprachen
[Bearbeiten]Die erste bekannte objektorientierte Programmiersprache war Simula-67. Später wurden die Prinzipien der Kapselung in einer Klassenhierarchie dann in Smalltalk weiter ausgebaut. Mit dem ANSI/X3.226-1994-Standard wurde Common Lisp/CLOS zur ersten standardisierten objektorientierten Programmiersprache und mit ISO 8652:1995 wurde Ada 95 als erste nach dem internationalen ISO-Standard normierte objektorientierte Programmiersprache festgelegt. Im Gegensatz dazu setzt Smalltalk, die älteste heute noch bedeutsame OOP-Sprache, auf kompromisslose Objektorientierung und hatte damit starken Einfluss auf die Entwicklung populärer OOP-Sprachen, ohne selber deren Verbreitung zu erreichen, weil keine kostengünstig allgemein verfügbare Implementierung angeboten wurde. Auch wenn der Durchbruch der OOP erst in den 1990er-Jahren stattfand, wurde die objektorientierte Programmierung bereits Ende der 1960er Jahre mit Simula-67 als Lösungsansatz für die Modularisierung und die Wiederverwendbarkeit von Code entwickelt.
Mischung - objektorientiert - prozedural
[Bearbeiten]Gängige moderne Programmiersprachen (z. B. Python) unterstützen sowohl die OOP als auch den prozeduralen Ansatz, der in den klassischen Programmiersprachen der 1970er- und 1980er-Jahre wie Pascal, Fortran oder C vorherrschte.
Aufgaben
[Bearbeiten]- Erzeugen Sie Objektklassen in der Open Source Software Umbrello[1] eine objektorientiertes Diagramm für eine Bibliothek oder Mediensammlung, bei der ein Bestand von Büchern oder Medien bestehen, den Nutzer:innen für eine begrenzte Zeit ausleihen können. Exportieren Sie die Klassen in eine Programmiersprache Ihrer Wahl!
- Welchen Anforderung sind für eine Datenbanksystem notwendig, die Bücher und Entleihe und Rückgabe für eine Liste von angemeldeten Benutzer:innen speichern kann?
- Wie können objektorientierte Programmierung und das Datenbanksystem zusammen die Aufgabe eines Entleihsystems umsetzen?
Techniken
[Bearbeiten]Objekt-Konzepte in Programmiersprachen
[Bearbeiten]In einigen objektorientierten Programmiersprachen wie Go, NewtonScript und Self wird auf die Deklaration von Klassen gänzlich verzichtet. Stattdessen werden neue Objekte von bestehenden Objekten, den sogenannten Prototypen, abgeleitet. Die Attribute und Methoden des Prototyps kommen immer dann zum Einsatz, wenn sie im abgeleiteten Objekt nicht explizit überschrieben wurden. Dies ist vor allem für die Entwicklung kleinerer Programme von Vorteil, da es einfacher und zeitsparend ist.
In manchen Programmiersprachen, beispielsweise in Objective-C, gibt es zu jeder Klasse ein bestimmtes Objekt (Klassenobjekt), das die Klasse zur Laufzeit repräsentiert; dieses Klassenobjekt ist dann auch für die Erzeugung von Objekten der Klasse und den Aufruf der korrekten Methode zuständig.
Klassen werden in der Regel in Form von Klassenbibliotheken zusammengefasst, die häufig thematisch organisiert sind. So können Anwender einer objektorientierten Programmiersprache Klassenbibliotheken erwerben, die zum Beispiel den Zugriff auf Datenbanken ermöglichen.
Entwurf von Objekt-Konzepten
[Bearbeiten]Die Wortarten einer sprachlichen Problembeschreibung können hilfreiche Hinweise dafür geben, eine Objekt-basierte Modellierung zu konzipieren (sogenannte Verb-Substantiv-Methode).[2] Dabei werden Objekte und Klassen in der Regel sprachlich durch Substantive beschrieben, wobei Eigennamen auf Objekte und Appellative wie Haus und Tier auf Klassen hindeuten.[3] Verben stehen in der Regel für Methoden, wobei Adverbien und Substantive ergänzende Charakterisierungen der Methoden geben können. Die Werte von Objektattributen entsprechen häufig Numeralien oder Adjektiven.[4]
Es gibt inzwischen auch Verfeinerungen der objektorientierten Programmierung durch Methoden wie Entwurfsmuster, Design by contract und grafische Modellierungssprachen wie die Unified Modeling Language.
Einen immer höheren Stellenwert nimmt die aspektorientierte Programmierung ein, bei der Aspekte von Eigenschaften und Abhängigkeiten beschrieben werden. Erste Ansätze sind beispielsweise in Java mit Jakarta EE oder der abstrakten Datenhaltung über Persistenzschichten sichtbar.
Grenzen der OOP
[Bearbeiten]Das objektorientierte Paradigma hat Vor- und Nachteile je nach Anwendungsfeld in der Softwaretechnik oder konkreter Problemstellung. Grundlegend muss man festhalten, dass allein die syntaktische Verfügbarkeit der objektierten Programmierung noch nicht dazu führt, dass eine durch die Software modelliertes System z.B. einen Wartungsvorteil bei der Fehlersuche hat. Wenn eine Strukturähnlichkeit zwischen OOP und realen System vorliegt
Beispiel - Bibliothekssystem
[Bearbeiten]Man betrachtet nun z.B. eine umgangssprachliche Beschreibung eines Problems:
- "Bei einem Entleihvorgang wird das Buch zwar als entliehen verbucht, aber der Datensatz der jeweiligen Nutzer:in über entliehene Bücher enthält das entliehen Buch nicht"
Wenn in der OOP nun jedem Objekt 'x' der Klasse 'Nutzer' eine Liste 'x.entlieheneBuecher' zugeordnet ist, kann man in der Methode der Klasse 'Bilbliothek'
Bilbliothek.entleiheFuer(pNutzer,pBuch)
überprüfen, obwohl in der Buchliste das Buch nicht nur ausgetragen wurde, sondern auch für den Nutzer 'pNutzer' Liste
pNutzer.entliehenBuecher.addBuch(pBuch)
das Buch 'pBuch' ergänzt wurde.
Bemerkung - Notation
[Bearbeiten]In der obigen Notation wurde für Parameter von Funktionen/Methoden ein vorangestelltes 'p' verwendet. Dies ist in der Syntax der OOP nicht verpflichtend, sondern eine Möglichkeit, bei konsistenter Anwendung lokale Variablen in Methoden von Parameter der Methode allein durch Namenskonvention zu unterscheiden.
Abbildung von Problemstellungen auf OOP-Techniken
[Bearbeiten]Die OOP kann, wie auch andere Programmierparadigmen, verwendet werden, Probleme aus der realen Welt abzubilden. Als ein typisches Beispiel für Problemstellungen, die sich einer geschickten Modellierung mit OOP-Techniken entziehen, gilt das Kreis-Ellipse-Problem.
Objektorientierte Programmiersprachen und natürliche Sprachen
[Bearbeiten]Objektorientierte Programmiersprachen können auch unter sprachwissenschaftlichen Aspekten mit natürlichen Sprachen verglichen werden. OO-Programmiersprachen haben ihren Fokus auf den Objekten, welche sprachlich Substantive sind. Die Verben (Aktionen) sind sekundär, fest an Substantive gebunden (gekapselt) und können im Allgemeinen nicht für sich allein stehen. Bei natürlichen Sprachen und z. B. prozeduralen Sprachen existieren Verben eigenständig und unabhängig von den Substantiven (Daten), z. B. als Imperativ und Funktion. Es kann argumentiert werden, dass diese sprachliche Einschränkung in einigen Anwendungsfällen zu unnötig komplizierten Beschreibungen von Problemen aus der realen Welt mit objektorientierten Sprachen führt.[5][6]
OOP und Kontrollfluss
[Bearbeiten]Häufig genannte Vorzüge des OOP-Paradigmas sind eine verbesserte Wartbarkeit und Wiederverwendbarkeit des statischen Quellcodes.[7] Hierzu werden jedoch die Kontrollflüsse und das dynamische Laufzeitverhalten den Daten/Objekten im Allgemeinen untergeordnet, abstrahiert und weggekapselt. Die Kontrollflüsse bilden sich nicht mehr für den Entwickler transparent direkt in den Codestrukturen ab (wie z. B. bei prozeduralen Sprachen), eine Umsetzung in dieser Hinsicht wird dem Compiler überlassen. Hardware-nähere Sprachen wie das prozedurale C oder Assembler bilden den echten Kontrollfluss und das Laufzeitverhalten transparenter ab.[8] Mit der wachsenden Bedeutung von paralleler Hardware und nebenläufigem Code wird jedoch eine bessere Kontrolle und Entwickler-Transparenz der komplexer werdenden Kontrollflüsse immer wichtiger – etwas, das schwierig mit OOP zu erreichen ist.[9][10]
OOP und relationale Datenbanken
[Bearbeiten]Ein häufig genannter Bereich, in dem OOP-Techniken als unzureichend gelten, ist die Anbindung von relationalen Datenbanken. OOP-Objekte lassen sich nicht direkt in allen Aspekten mit relationalen Datenbanken abbilden. Umgekehrt können über OOP die Stärken und Fähigkeiten von relationalen Datenbanken ebenfalls nicht vollständig ausgeschöpft werden. Die Notwendigkeit, eine Brücke zwischen diesen beiden Konzeptwelten zu schlagen, ist als object-relational impedance mismatch bekannt. Hierzu existieren viele Ansätze, beispielsweise die häufig verwendete objektrelationale Abbildung, jedoch keine allgemeingültige Lösung ohne den einen oder anderen Nachteil.[11]
Laufzeitverhalten und Energieeffizienz
[Bearbeiten]Die Effektivität des Laufzeitverhaltens von Anwendungen, die auf OOP-Techniken basieren, wird seit jeher kontrovers diskutiert. Alexander Chatzigeorgiou von der Universität Makedonien verglich die Laufzeiteffektivität und die Energieeffizienz von typischen Algorithmen (Gauß-Jordan-Algorithmus, Trapez-Integration und QuickSort) von prozeduralen Ansätzen und OOP-Techniken, implementiert als C- und C++-Software. Auf dem verwendeten ARM-Prozessor ergab sich für drei Algorithmen im Mittel eine um 48,41 % bessere Laufzeiteffektivität mit den prozeduralen C-Algorithmusvarianten. Es ergab sich außerdem eine im Mittel um 95,34 % höhere Leistungsaufnahme der C++-Varianten zu den C-Varianten.[12] Für Anwendungen auf mobilen Geräten, wie Handys oder MP3-Spielern mit begrenzten Leistungs- und Energiespeichervermögen, sind derartige Unterschiede signifikant, allerdings machen derartige Algorithmen in der Regel nur einen Bruchteil der Applikationen aus. Als Grund für den Unterschied in Effektivität und Energieeffizienz werden in dem Artikel generelle Abstraktions-Leistungseinbußen und die deutlich größere Anzahl von Zugriffen auf den Arbeitsspeicher durch OOP-Techniken genannt.
Literaturquellen
[Bearbeiten]- ↑ Umbrello (2022) Open Source UML Modelling Software for Linux, Windows, MacOSX - URL: https://uml.sourceforge.io (abgerufen 2025/12/15)
- ↑ David J. Barnes, Michael Kölling: Java lernen mit BlueJ: Eine Einführung in die objektorientierte Programmierung. München 2009, ISBN 978-3-86894-001-5, S. 496.
- ↑ Russell J. Abbott: Program design by informal English descriptions. In: Communications of the ACM. 26. Jahrgang, 1983, S. 882–894, doi:10.1145/182.358441.
- ↑ Jörg Bewersdorff: Objektorientierte Programmierung mit JavaScript: Direktstart für Einsteiger. 2. Auflage. Wiesbaden 2018, ISBN 978-3-658-21076-2, S. 30–33, doi:10.1007/978-3-658-21077-9_4.
- ↑ Steve Yegge: Execution in the Kingdom of Nouns. steve-yegge.blogspot.com. 30. März 2006. Abgerufen am 3. Juli 2010..
- ↑ Timothy Boronczyk: What’s Wrong with OOP. zaemis.blogspot.com. 11. Juni 2009. Abgerufen am 3. Juli 2010..
- ↑ Scott Ambler: A Realistic Look at Object-Oriented Reuse. drdobbs.com. 1. Januar 1998. Abgerufen am 4. Juli 2010..
- ↑ Asaf Shelly: Flaws of Object Oriented Modeling. Intel® Software Network. 22. August 2008. Abgerufen am 4. Juli 2010..
- ↑ Justin James: Multithreading is a verb not a noun. techrepublic.com. 1. Oktober 2007. Abgerufen am 4. Juli 2010..
- ↑ Asaf Shelly: HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions. support.microsoft.com. 22. August 2008. Abgerufen am 4. Juli 2010..
- ↑ Ted Neward: The Vietnam of Computer Science. Interoperability Happens. 26. Juni 2006. Archiviert vom Original am 4. Juli 2006. Abgerufen am 2. Juni 2010..
- ↑ Alexander Chatzigeorgiou: Performance and power evaluation of C++ object-oriented programming in embedded processors. In: Information and Software Technology. 45. Jahrgang, Nr. 4, 2003, ISSN 0950-5849, S. 195–201, doi:10.1016/S0950-5849(02)00205-7.
Siehe auch
[Bearbeiten]- Open Source Migration
- Objektorientierte Mathematische Modellbildung
- Geschichte der Programmiersprachen
- Liste objektorientierter Programmiersprachen
- Objektbasierte Programmiersprache
Seiteninformation
[Bearbeiten]Wikipedia2Wikiversity
[Bearbeiten]Diese Seite wurde auf Basis der folgenden Wikipedia-Quelle erstellt: