2023-2-WS_fdai7859/Programmierparadigmen.md

# Programmierparadigmen

## Java
 - Ähnlichkeiten zu C und C++
 - Standardbibliothek
 - strikt typisiert
 - objektorientierte Programmiersprache (Klassen, Vererbung)
 - funktional (Lambda-Funktion)
 - imperativ
 - Webanwendung, Desktopanwendung 

## C
 - imperative Programmiersprache
 - prozedurale Programmiersprache
 - typisierte
 - Anwendung: Hardwarenahe Programmierung, direkter Speicherzugriff
 - kann auf allen Systemen verwendet werden
 - kleine Standardbibliothek (kleiner Befehlssatz)

## Python
 - Python basiert auf C und C++
 - fällt in die Kategorie der interpretierten Sprachen, da kein Compiler benötigt wird
 - imperative
 - prozedurale
 - deklarative
 - funktionale
 - objektorientierte
 - typisierte (im Hintergrund)

## go
 - einfach und lesbar und effizient (durch low-level-Sprache)
 - Es besitzt eine Standardbibliothek
 - Orientiert sich an C.
 - objektorientierte Programmiersprache (Objekte, aber keine Klassen)
 - typisiert
 - imperativ

## JavaScript
 - basiert auf C
 - typisiert
 - imperativ
 - funktionale (Ursprüngliche Daten werden nicht verändert/ nur in Funktionen)
 - objektorientiert (Klassenlos)
 - Moduleerstellung
 - Universelle Benutzung
 - interaktiv
 - Kompatibilitätsprobleme bei unterschiedlichen Browsern
 - Webapplikation
 - asynchrone Verarbeitung (Callback)

## TypeScript
 - baut auf Java Script auf
 - Starke Typisierung
 - Statische und dynamische Datentypen
 - Webapplikationen
 - objektorientiert
 - funktional
 - imperativ


# Programmierprinzipien

## SOLID

### Separations of Concern
Module sollten einem und nur einem Akteur gegenüber verantwortlich sein

### Open/Closed Principle
Bei der Entwicklung von Klassen, Methoden, Modulen usw. sollen Erweiterungen einfach implimentierbar sein,
aber ohne die bestehenden Verhältnisse zu verändern.

### Liskov Substitution Principle
Subklassen sollen immer Eigenschaften der Superklasse erfüllen und auch als solche verwendet werden können.

### Interface Segregation Principle
Interfaces sollen an Bedürfnis des Client angepasst werden und nicht übermäßig überladen werden.

### Dependency Inversion Principle
Module höherer Ebene sollten nicht von Modulen niedriger Ebene abhängen. Beide sollten von Abstraktionen abhängen.
Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.

## STUPID

### Singelton
Es wird nur genau ein Objekt pro Klasse erzeugt und global zur Verfügung gestellt.
Es kann dadurch zu Abhängigkeiten führen, die man nicht direkt sehen kann.

### Tight Coupling
Module zu stark verkuppelt, dass Änderungen in einem Modul immer zu einer weiteren Änderung führen müssen.
Isolierte Testungen sind so fast unmöglich.

### Untestability
Untestbarkeit von Modulen (z.B. durch Tight Coupling)

### Premature Optimization
Frühzeitige Optimierung bevor überhaupt Probleme entstanden sind (viel Zeit für nichts).

### Indescriptive Naming
Ungenaue Benennung von Variablen, Funktionen usw. Andere Programmierer haben Probleme diesen Code nachzuvollziehen.

### Duplication
Keine Dopplung von den selben Code. Änderung müssen mehrmals vorgenommen werden.