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