2023-2-WS_fdai7723/Programmierparadigmen.md

# Programmiersprachen:

## Java

- imperativ
- Streng typisiert
- objektorientiert
- funktionale Sprache


## C

- Imperativ
- Streng typisiert
- Vorteil: Hardwarenähe, Kompatibilität
- Schnelligkeit
- Nachteil: Speicherverwaltung

## Phyton

- Imperativ
- Objektorientiert
- Klassen und Objekte
    - Hieratchien
- Funktional
    - kompakte Syntax
- interpretierte Sprache
    - Übersetzung in andere Sprachen möglich (Cython, etc.)
- Portabilität
- Typisierung
    - Dynamisch (Duck Typing)

## Go

- Modular, imperativ
- breite Palette an Programmierparadigmen
- Teilweise Objektorientiert & Funktional
    - keine Vererbung
    - statt Klassen werden Structs verwendet
- Einfache, effektive Programmierung
- Typisierung: Statisch typisiert
    - vor der Kompilierung müssen Typen fest stehen
- Schnelligkeit von C & Anwendungsmöglichkeiten/Simplizität von Python
- Multi-Threading

## JavaScript/TypeScript

- Erweiterung von HTML
- Multi-Paradigmen
    - OOP, Prozedural oder Funktional
- Dynamische Typisierung
- Andwendung: Interaktive Web-Anwendungen (z.B. Goolge Maps)
- Vorteile: modernes Erscheinungsbild, günstiger Server-Traffic (läuft im Browser)
    - Dynamische Elemente
    - Event-basiert (Callbacks)
    - asynchrone Verarbeitung

## TypeScript

- typisiert
- imperativ, OOP
    - je nach Anforderungen: prozedural oder funktional
- TS hat Einfluß von JS/Java/C#
- baut auf Supermenge von JS Bibliotheken auf
- Skalierbarkeit/Wartbarkeit -> durch Einführung OOP
        
# Programmierprinzipien:

## DO IT

- (S) eparation of Concern (Programme aufteilen in kleine Teile, Methoden, Funktionen, Prozeduren)
- (O) pen/Closed Priciple (einfach neue Funktionalität zuzufügen, Änderungen bleiben lockal und haben keine Auswirkunng nach Aussen)
- (L) iskov Substitution Principle (so Code schreiben, dass andere keine Überraschungen mit ihrem Code hben)
- (I) nterface Segregation Principle (Clients sollen nicht gezwungen sein, die Schnittstellen abhängige Methoden zu implementieren. die sie nicht verwenden.Dies führt zu Schnittstellen, die nur die benötigten Methoden enthalten.)
- (D) ependency Inversion Principle (Teil der Logik in andere Klassen auslagern)

## DON'T DO IT

- (S) ingleton (zur Laufzeit des Programms gibt es nur eine Kopie des Codes)
- (T) ight Coupling (Teile die nichts miteinander zu tun haben sind sehr verbunden und die kann man nicht teilen)
- (U) ntestability (Code der sich nicht automatisiert testen lässt)
- (P) remature Optimisation (um Performance sich kümmern, erst wenn man Performance bereits hat; erst nach der Messung und nach der Nachweis, dass es diese Stelle ist)
- (I) ndescriptive Naming (ungenügende oder falsche Beschreibung anstatt die Bezeicher so zu benennen, dass sich selbst beschreiben)
- (D) uplication (duplizieren von Code; besser ist es ein wiederholendes Code in eine zentrale Strucktur auszulagern)