Übung 2

Programmierparadigmen.md

@@ -0,0 +1,66 @@
+# Analyse der Programmiersprachen
+
+## Java
+- **Paradigma**: Hauptsächlich Objektorientiert, unterstützt auch imperative und prozedurale Programmierung.
+- **Vorteile**: Starke Typisierung, gute Wiederverwendbarkeit von Code, fördert modulare Programmierung.
+- **Nachteile**: Weniger geeignet für funktionale Programmierung, kann umständlicher sein für kleine Projekte.
+
+## C
+- **Paradigma**: Imperativ und prozedural.
+- **Vorteile**: Nähe zur Hardware, hohe Performance, Kontrolle über Speichermanagement.
+- **Nachteile**: Keine Unterstützung für objektorientierte oder funktionale Programmierung, höheres Risiko für Speicherfehler.
+
+## Python
+- **Paradigma**: Multiparadigmatisch – unterstützt objektorientierte, imperative, prozedurale und in begrenztem Maße funktionale Programmierung.
+- **Vorteile**: Einfache Syntax, vielseitig einsetzbar, große Standardbibliothek.
+- **Nachteile**: Langsamer als kompilierte Sprachen, dynamische Typisierung kann zu Laufzeitfehlern führen.
+
+## Go
+- **Paradigma**: Hauptsächlich prozedural und imperativ, mit einigen Elementen aus der objektorientierten Programmierung.
+- **Vorteile**: Einfache Syntax, gute Unterstützung für Nebenläufigkeit (Concurrency), effiziente Speicherverwaltung.
+- **Nachteile**: Eingeschränkte Generika-Unterstützung, fehlende Funktionen für objektorientierte Programmierung im Vergleich zu anderen Sprachen.
+
+## JavaScript
+- **Paradigma**: Hauptsächlich objektorientiert und funktional, unterstützt auch imperative Programmierung.
+- **Vorteile**: Hohe Flexibilität, dynamische Typisierung, weit verbreitet im Web.
+- **Nachteile**: Inkonsequenzen im Sprachdesign, dynamische Typisierung kann zu unerwarteten Fehlern führen.
+
+## TypeScript
+- **Paradigma**: Objektorientiert, funktional und imperativ; Erweiterung von JavaScript.
+- **Vorteile**: Statische Typisierung für JavaScript, bessere Tools zur Fehlerfindung zur Entwicklungszeit, kompatibel mit JavaScript.
+- **Nachteile**: Erfordert Kompilierung, kann in komplexen Projekten zusätzliche Komplexität einführen.
+
+## Programmierprinzipien
+
+### 1. SOLID
+- **Langbezeichnung**: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
+- **Beschreibung**: Fünf zentrale Prinzipien der objektorientierten Programmierung und des Software-Designs. Sie unterstützen die Entwicklung von wartbarer, verständlicher und erweiterbarer Software.
+
+### 2. DRY
+- **Langbezeichnung**: Don't Repeat Yourself
+- **Beschreibung**: Dieses Prinzip zielt darauf ab, Wiederholungen von Softwaremustern zu vermeiden. Es verbessert die Wartbarkeit, indem Redundanzen im Code reduziert werden.
+
+### 3. TDD
+- **Langbezeichnung**: Test-Driven Development
+- **Beschreibung**: Ein Ansatz in der Softwareentwicklung, bei dem Tests vor der Implementierung des eigentlichen Codes geschrieben werden, um sauberen und fehlerfreien Code zu fördern.
+
+### 4. BDD
+- **Langbezeichnung**: Behavior-Driven Development
+- **Beschreibung**: Eine Weiterentwicklung von TDD, die darauf fokussiert ist, das Verhalten einer Softwareanwendung durch beispielhafte Szenarien in verständlicher Sprache zu definieren.
+
+### 5. LSP
+- **Langbezeichnung**: Liskov Substitution Principle
+- **Beschreibung**: Ein Prinzip des SOLID-Prinzips, das aussagt, dass Objekte einer Superklasse durch Objekte ihrer Unterklassen ersetzt werden können, ohne die Funktionalität des Programms zu beeinträchtigen.
+
+### 6. CCP
+- **Langbezeichnung**: Common Closure Principle
+- **Beschreibung**: Klassen, die sich gemeinsam ändern, sollten in einem Paket gruppiert werden. Dadurch werden unbeabsichtigte Auswirkungen auf andere Softwareteile minimiert.
+
+### 7. CRP
+- **Langbezeichnung**: Common Reuse Principle
+- **Beschreibung**: Empfiehlt, dass Klassen, die in einem Paket gruppiert sind, gemeinsam wiederverwendet werden sollten, um unerwünschte Abhängigkeiten zu vermeiden.
+
+### 8. OCP
+- **Langbezeichnung**: Open-Closed Principle
+- **Beschreibung**: Ein weiteres SOLID-Prinzip, das besagt, dass Softwarekomponenten für Erweiterungen offen, jedoch für Modifikationen geschlossen sein sollten.
+