fdai7723
1 year ago
1 changed files with 84 additions and 0 deletions
@ -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 |
||||
|
|
||||
|
##JavaScript/TypeScript |
||||
|
|
||||
|
*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 |
||||
|
|
||||
|
##TypeScript |
||||
|
|
||||
|
*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) |
Write
Preview
Loading…
Cancel
Save
Reference in new issue