3.3 KiB
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.