|
|
# 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.
|
