Die objektorientierte Programmierung

Die OOP ist ein Programmierparadigma, das auf dem Konzept von "Objekten" basiert. Das Programm ist in Segmente von Objekten unterteilt, die miteinander kommunizieren. Jedes Objekt ist definiert durch: seine Funktionen (Methoden) und seine Daten (Eigenschaften). Um eine OOP-Sprache zu sein, muss die Programmiersprache eine Liste von OOP-Bedingungen, -Prinzipien und -Eigenschaften erfüllen.

Principles of Object-Oriented-Programming:

Inheritance (Keyword: extends):
Wenn mehrere Klassen gemeinsame Attribute (variables) und Verhalten (methods) haben, werden diese gemeinsamen Teile extrahiert und in einer öffentlichen Klasse definiert. Andere Klassen können mit dieser öffentlichen Klasse eine Vererbungsbeziehung eingehen, so dass der öffentliche Teil nicht in mehreren Klassen neu definiert werden muss! Diese gemeinsame Klasse ist die übergeordnete Klasse, die auch als Parent/Base/Superclass bezeichnet wird, und die anderen Klassen sind die Unterklassen(Childs/Subclasses). Unterklassen können direkt auf nicht-private Variablen des Parents zugreifen.

Polymorphism:
Polymorphismus ("viele Formen") ist die Implementierung eines Objekts mit verschiedenen Manifestationen. Ein Beispiel für Polymorphismus: Dieselbe Taste (z.B. "ENTER") kann in verschiedenen Applikationen, unterschiedliche Aktionen auslösen ("Zeilenvorschub", "Senden", "Öffnen"). Das Drücken der "ENTER"-Taste spielt in verschiedenen Anwendungen eine andere Rolle. Polymorphism hilft bei der Skalierbarkeit, Flexibilität und Vereinfachung von Applikationen. Polymorphism kann als Schnittstelle arbeiten und unterstützt darin, die Kopplung zwischen Klassen aufzuheben.

Encapsulation:
Wir fassen die Objekte zusammen, die die gleichen Eigenschaften haben oder zur gleichen Klasse gehören, und versuchen dadurch Coupling zu vermeiden.

Loose Coupling:
Unter Coupling versteht man den Grad der gegenseitigen Abhängigkeit zwischen Klassen/Modulen. Die Kopplung ist ein Maß dafür, wie zwei oder mehr Komponenten voneinander abhängen. Wenn eine Ihrer Komponenten nicht mehr funktioniert, wenn die andere Komponente ausgefallen ist, sind sie fest gekoppelt. Rückblickend gilt: Je weniger diese Komponenten voneinander abhängig sind, desto lockerer sind sie gekoppelt. Ein starkes Coupling sollte im Sinne der objektorientierten Programmierung vermieden werden. Idealerweise möchten wir, dass unsere Komponenten zu 100 % unabhängig sind.

The SOLID-Principles

Die Design-Patterns sind Techniken aus der objektorientierten Programmierung und folgen dementsprechend folgenden Prinzipien.

Single-Responsibility-Prinzip:
Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine Aufgabe haben sollte. Der Grund für dieses Prinzip ist die Trennung von Verantwortlichkeiten oder Verhaltensweisen, damit Debugging und Refactoring keine Probleme für andere Teile eines Projekts verursachen.

Open-closed-Principle:
Unsere Klassen sollen offen gegenüber Erweiterungen sein aber geschlossen für Modifikationen.

Liskov-substitution-Principle:
Das Liskov-Substitutionsprinzip besagt, dass bei einer Vererbung, eine Elternklasse problemlos durch ihre Kindklasse ersetzt werden kann. Dies liegt daran, dass die untergeordnete Klasse bei der Vererbung in der Lage sein sollte, alles zu tun, was die übergeordnete Klasse kann, und die gleichen und verbesserten Ergebnisse liefern.

Interface Segregation Principle: (keyword: implements)
Unter dem Prinzip der Schnittstellentrennung versteht man, dass ein Client niemals gezwungen werden sollte, eine Schnittstelle zu implementieren, die er nicht verwendet. Ebenso sollten Clients nicht gezwungen werden, sich auf Methoden zu verlassen, die sie nicht verwenden. Das Ziel dieses Prinzips ist es, unnötigen Code aus Klassen zu entfernen, um unerwartete Fehler zu reduzieren. Wir teilen Aktionen in kleinere Sets auf, damit eine Klasse nur die Aktionen ausführt, die sie benötigt.

Dependency Inversion Principle:
Das Dependency Inversion Principle (Abhängigkeits-Umkehr-Prinzip) besagt, dass Entitäten von Abstraktionen abhängen müssen, nicht von Konkretionen. High-Level-Module(Klassen, die ein Tool/ eine Library implementieren), sollten nicht von Low-Level-Modulen (die Tools oder Librarys, die zum Ausführen einer Aktion benötigt werden) abhängen. Beides sollte von der Abstraktion abhängen. Abstraktionen sollten nicht von Details sondern Details sollten von Abstraktionen abhängen. Das Prinzip ermöglicht die Entkopplung. Dies hilft uns, Abhängigkeiten zu reduzieren und in Zukunft eine einfachere Implementierung anderer Tools zu ermöglichen.