Woche 2, Programmiersprachen/Programmierparadigmen.

Programmierparadigmen.md

@@ -0,0 +1,84 @@
+#Programmiersprachen:
+
+    ##Java
+
+        *imperativ
+        *Streng typisiert
+        *objektorientiert
+        *funktionale Sprache
+
+
+    ##C
+
+        *Imperativ
+        *Streng typisiert
+        *Vorteil: Hardwarenähe, Kompatibilität
+        *Schnelligkeit
+        *Nachteil: Speicherverwaltung
+
+    ##Phyton
+
+        *Imperativ
+        *Objektorientiert
+            *Klassen und Objekte
+            *Hieratchien
+        *Funktional
+            *kompakte Syntax
+        *interpretierte Sprache
+            *Übersetzung in andere Sprachen möglich (Cython, etc.)
+        *Portabilität
+        *Typisierung
+            *Dynamisch (Duck Typing)
+
+    ##Go
+
+        *Modular, imperativ
+        *beite Palette an Programmierparadigmen
+        *Teilweise Objektorientiert & Funktional
+            *keine Vererbung
+            *statt Klassen werden Structs verwendet
+        *Einfache, effektive Programmierung
+        *Typisierung: Statisch typisiert
+            *vor der Kompilierung müssen Typen fest stehen
+        *Schnelligkeit von C & Anwendungsmöglichkeiten/Simplizität von Python
+        *Multi-Threading
+
+    ##JS/TS
+
+        *Erweiterung von HTML
+        *Multi-Paradigmen
+            *OOP, Prozedural oder Funktional
+        *Dynamische Typisierung
+        *Andwendung: Interaktive Web-Anwendungen (z.B. Goolge Maps)
+        *Vorteile: modernes Erscheinungsbild, günstiger Server-Traffic (läuft im Browser)
+            *Dynamische Elemente
+        *Event-basiert (Callbacks)
+            *asynchrone Verarbeitung
+
+    ##TS
+
+        *typisiert
+        *imperativ, OOP
+            *je nach Anforderungen: prozedural oder funktional
+        *TS hat Einfluß von JS/Java/C#
+        *baut auf Supermenge von JS Bibliotheken auf
+        *Skalierbarkeit/Wartbarkeit -> durch Einführung OOP
+        
+#Programmierprinzipien:
+
+    ##DO IT
+
+        (S) eparation of Concern (Programme aufteilen in kleine Teile, Methoden, Funktionen, Prozeduren)
+        (O) pen/Closed Priciple (einfach neue Funktionalität zuzufügen, Änderungen bleiben lockal und haben keine Auswirkunng nach Aussen)
+        (L) iskov Substitution Principle (so Code schreiben, dass andere keine Überraschungen mit ihrem Code hben)
+        (I) nterface Segregation Principle (Clients sollen nicht gezwungen sein, die Schnittstellen abhängige Methoden zu implementieren. die sie nicht verwenden.Dies führt zu Schnittstellen, die nur die             benötigten Methoden enthalten.)
+        (D) ependency Inversion Principle (Teil der Logik in andere Klassen auslagern)
+
+    ##DON'T DO IT
+
+        (S) ingleton (zur Laufzeit des Programms gibt es nur eine Kopie des Codes)
+        (T) ight Coupling (Teile die nichts miteinander zu tun haben sind sehr verbunden und die kann man nicht teilen)
+        (U) ntestability (Code der sich nicht automatisiert testen lässt)
+        (P) remature Optimisation (um Performance sich kümmern, erst wenn man Performance bereits hat; erst nach der Messung und nach der Nachweis, dass es diese Stelle ist)
+        (I) ndescriptive Naming (ungenügende oder falsche Beschreibung anstatt die Bezeicher so zu benennen, dass sich selbst beschreiben)
+        (D) uplication (duplizieren von Code; besser ist es ein wiederholendes Code in eine zentrale Strucktur auszulagern)