# Programmierparadigmen von verschiedenen Programmiersprachen 


## Übung 02.11.2023



### Java

Imperativ

Objekt-orientiert (OOP)

Streng objekt-orientiert

Konzept: Klassen/Objekte

Vererbung/Kapselung/Polymorphie

Modellierung komplexer Probleme leichter

Wartbar/Skalierbar

Plattform unabhängig

-> Cross-Plattform Kompatibilität

Multi-Threaded

Funktional (seit neueren Versionen)



### C 

Imperative Programmiersprache 

Prozedurale Programmiersprache

Weitergabe von Daten über Funktionen

Typisierte Programmiersprache

-> Streng typisiert

Vorteil: Hardwarenähe, Kompatibilität

Schnelligkeit

Nachteil: Speicherverwaltung



### Python

Imperativ

Objekt-orientiert

Klassen und Objekte

Hierarchien

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

Einache, effektive Programmierung

Typisierung: Statisch typisiert

Vor der Kompilierung müssen Typen fest stehen

Mix: Schnelligkeit von C & Anwendungsmöglichkeiten/Simplizität von Python

Multi-Threading



### JavaScript

Erweiterung von HTML

Multi-Paradigmen

OOP, Prozedural oder Funktional

Dynamische Typisierung

Anwendung: Interaktive Web-Anwendungen (z.B. Google Maps)

Vorteile: Modernes Erscheinungsbild, Günstiger Server-Traffic (läuft im Browser)

Dynamische Elemente 

Event-basiert (Callbacks)

Asynchrone Verarbeitung



### TypeScript

Typisiert

Imperativ, OOP

Vererbung

TypeScript hat Einfluss von JavaScript/Java/C#

Baut auf Supermenge von JavaScript Bibliotheken auf

Skalierbarkeit/Wartbarkeit -> Durch Einführung OOP



### SOLID

# Separations of Concern

Eine Klasse sollte nur für eine Funktion verantwortlich sein.

# Open/Closed Principle

Offen für Erweiterungen, aber geschlossen für Modifikationen.


# Liskov Substitution Principle

Objekte einer abgeleiteten Klasse sollte ohne, dass die Funktionalität des Programms eingeschränkt wird, anstelle von Objekten der Basisklasse verwendet werden können.

# Interface Segregation Principle

Clients sollten nicht von Schnittstellen abhängig sein, welche nicht verwendet werden.


# Dependency Inversion Principle

Module sollten nicht von einander abhänig sein, sondern von abstrakten Schnittstellen.






### STUPID

# Singelton

Es wird nur ein Objekt in einer Klasse erzeugt, wenn diese global zur Verfügung stehen, kann das die Testbarkeit beeinträchtigen.

# Tight Coupling

Teile die nichts miteinander zu tun haben, sind dennoch eng miteinander verbunden. Dies sollte nicht geschehen.

# Untestability

Untestbarkeit z.B. aufgrund von Tight Coupling, was zu Qualitätsverlust des Codes führen kann.

# Premature Optimization

Man sollte erst etwas Optimieren, wenn es auch nötig ist, sonst verschwendet man viel Zeit.

# Indescriptive Naming

Wenn man etwas ungenau benennt, kann das für andere Programmierer, die den Code ansehen, Probleme mit der Nachvollziehbarkeit machen.

# Duplication

Man sollte denselben Code nicht doppeln, da man jedes mal, wenn man etwas am Original verändert, auch bei den gedoppelten Codes die Veränderung vornehmen muss.