Abstraktes Bild einer Frau, die auf Büchern sitzt und an einem Laptop studiert

Prinzipiensprachen

Als PPTX, PDF herunterladen
1&1, profile picture
1&1

Das Dokument präsentiert die Prinzipien und Prinzipiensprachen für Softwaredesign, die darauf abzielen, gute Lösungen von schlechten zu unterscheiden. Wichtige Prinzipien wie 'Keep It Simple, Stupid' (KISS) und 'Murphy's Law' werden erörtert, um die Modularität, Verständlichkeit und Wiederverwendbarkeit von Software zu fördern. Darüber hinaus wird in dem Dokument auf die Bedeutung von Prinzipien und deren Vernetzung in einem Wiki hingewiesen, um Entscheidungsfindungen und Kommunikation zu verbessern.

1 von 85
Downloaden Sie, um offline zu lesen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
Prinzipiensprachen Christian Rehn – 1&1 Source Center 1
Organisatorisches  Folien enthalten nur wenig Text  Besser für Präsentation  Zusätzlich ausführlichere Vortragsnotizen online  Die Vortragsnotizen geben nicht notwendigerweise 1:1 den Vortrag wieder  Feedback erwünscht  Bei Fragen  Fragen!  Wenn kurze Antworten möglich sind, gleich  Ansonsten zum Ende eines Kapitels ® 1&1 Internet AG 2013 2
Vorstellung – Wer erzählt das hier alles eigentlich?  Christian Rehn, 25 Jahre, Softwareentwickler  Informatikstudium an der TU Kaiserslautern  Seit Mai im 1&1 Source Center  Blog: http://www.christian-rehn.de  Wiki: http://www.principles-wiki.net  E-Mail: christian.rehn@1und1.de ® 1&1 Internet AG 2013 3
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 4
Geschichte Es war einmal… ® 1&1 Internet AG 2013 5
Geschichte QBasic, Delphi, … ® 1&1 Internet AG 2013 6
Geschichte ® 1&1 Internet AG 2013 7
Geschichte ® 1&1 Internet AG 2013 8
Geschichte ® 1&1 Internet AG 2013 9
BibDB ® 1&1 Internet AG 2013 10
Warum? Was unterscheidet gute Lösungen von schlechten? ® 1&1 Internet AG 2013 11
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 12
Was unterscheidet gute Lösungen von schlechten?  Bewertung, nicht Generierung von Lösungen  Nicht: „Wie komme ich auf eine Lösung?“  Irgendwelche Lösungen zu finden, ist oft gar nicht das Problem  Sondern: „Wie weiß ich, ob das gut ist?“ ® 1&1 Internet AG 2013 13
Es gibt viele Prinzipien ® 1&1 Internet AG 2013 14
Prinzip: Definition Ein Prinzip ist eine Daumenregel, die gute von schlechten Lösungen unterscheidet – in Bezug auf einen Entwurfsaspekt. ® 1&1 Internet AG 2013 15
Information Hiding/Encapsulation (IH/E) “Objekte sind wie Abwasserleitungen” ® 1&1 Internet AG 2013 16
Murphy‘s Law (ML) “Whatever can go wrong, will go wrong” ® 1&1 Internet AG 2013 17
Murphy‘s Law (ML) ® 1&1 Internet AG 2013 18
Murphy‘s Law (ML) “If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.” ® 1&1 Internet AG 2013 19
Murphy‘s Law (ML) “Whatever can go wrong, will go wrong” ® 1&1 Internet AG 2013 20
Murphy‘s Law (ML)  Aussage  Alles was schief gehen kann, wird irgendwann schiefgehen. Also ist eine Lösung dann besser, wenn sie weniger Möglichkeiten zulässt, dass etwas schiefgeht.  Begründung  Menschen machen Fehler und das wird sich nie grundlegend ändern. Statistisch gesehen wird also auf lange Sicht, eine Fehler-Möglichkeit auch zu einem Fehler führen.  Beispiel  Date date1 = new Date(2013, 01, 12); ® 1&1 Internet AG 2013 21
Murphy‘s Law (ML) “new Date(2013, 01, 12);” ® 1&1 Internet AG 2013 22
Keep It Simple Stupid (KISS) ® 1&1 Internet AG 2013 23
Keep It Simple Stupid (KISS) “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” – Tony Hoare ® 1&1 Internet AG 2013 24
Keep It Simple Stupid (KISS)  Aussage  Einfache Lösungen sind besser als komplizierte.  Begründung  Wenn etwas einfacher ist, kann man es einfacher verstehen und ändern.  Wenn etwas einfacher ist, macht man weniger Fehler.  Beispiel  Eine Lösung ohne komplizierte Sprachfeatures wie polymorphe Enums, innere Klassen und tiefe Vererbungshierarchien, … ® 1&1 Internet AG 2013 25
Generalization Principle (GP)  Aussage  Mächtige, allgemein anwendbare Lösungen sind besser als Speziallösungen.  Begründung  Allgemeine Lösungen sind wiederverwendbar  Wenn sich die Anforderungen ändern, muss man spezielle Lösungen eher ändern  Beispiel  Funktionen mit Parametern, wiederverwendbare Klassen, Generics, … ® 1&1 Internet AG 2013 26
Problem Prinzipien widersprechen einander ® 1&1 Internet AG 2013 27
Beispiel  Anforderung:√2 wird benötigt  Mehrere Möglichkeiten 1. final double SQRT_2 = 1.4142135623730951; 2. double sqrt_2() {…} 3. double sqrt(double r) {…} 4. double power(double base, double exponent) {…} 5. class ComplexPolynomRootCalculator ® 1&1 Internet AG 2013 28
Pareto-Optimum ® 1&1 Internet AG 2013 29
Tradeoff Tradeoff ® 1&1 Internet AG 2013 30
Principle of Separate Understandability (PSU)  Aussage  Jedes Modul sollte separat verständlich sein.  Begründung  Andere Module lesen und verstehen zu müssen kostet unnötig Zeit und ist fehleranfällig.  Beispiel  … folgt auf den nächten Folien … ® 1&1 Internet AG 2013 31
Principle of Separate Understandability (PSU) // Anforderung: printStatistics('d', 0); // „There are 0 ds“ printStatistics('d', 1); // „There is 1 d“ printStatistics('d', 25); // „There are 25 ds“ ® 1&1 Internet AG 2013 32
Principle of Separate Understandability (PSU) private void printStatistics( } else { number = char ch, int count) { String number; String verb; Integer.toString(count); String pluralModifier; verb = "are"; if (count == 0) { pluralModifier = "s"; number = "no"; } verb = "are"; String message = String.format("There %s %s pluralModifier = "s"; %s%s", verb, number, ch, } else if (count == 1) { pluralModifier); number = "1"; verb = "is"; pluralModifier = ""; ® 1&1 Internet AG 2013 System.out.println(message); } 33
Principle of Separate Understandability (PSU) class StatisticsMessage { private String number; private String verb; private String pluralModifier; … public String make( char ch, int count) { createMessageParts(count); return String.format( "There %s %s %s%s", verb, number, ch, private void createMessageParts( int count) { if (count == 0) thereAreNoLetters(); else if (count == 1) thereIsOneLetter(); else thereAreManyLetters(count); } private void thereAreNoLetters() { number = "no"; verb = "are"; pluralModifier = "s"; } … pluralModifier); } ® 1&1 Internet AG 2013 34
Principle of Separate Understandability (PSU) private String composeStatistics(char candidate, int count) { Number number = requiresPluralForm(count) ? PLURAL : SINGULAR; return "There " + thirdFormOfToBe(number) + " " + countToString(count) + " " + declineLetter(candidate, number)); } ® 1&1 Internet AG 2013 35
Principle of Separate Understandability (PSU) private boolean requiresPluralForm(int count) { return count != 1; } private String thirdFormOfToBe(Number number) { return number == SINGULAR ? "is" : "are"; } private String countToString(int count) { return count == 0 ? "no" : Integer.toString(count); } private String declineLetter(char letter, Number number) { return number == SINGULAR ? Character.toString(letter) : letter + "s"; } ® 1&1 Internet AG 2013 36
Module Communication Module Communication ® 1&1 Internet AG 2013 37
Ripple Effects und Shotgun Surgery ® 1&1 Internet AG 2013 38
Kommunikation beschränken ® 1&1 Internet AG 2013 39
Bindung und Kopplung  Cohesion/Bindung  Maß für den Zusammenhalt eines Moduls  Coupling/Kopplung  Maß für die Abhängigkeiten zwischen den Modulen ® 1&1 Internet AG 2013 40
HC, LC und Abstraktionsstufen ® 1&1 Internet AG 2013 41
Low Coupling (LC)  Aussage  Die Kopplung zwischen Modulen sollte lose sein.  Begründung  Eine starke Kopplung zwischen den Modulen A und B bedeutet, dass o.B.d.A. Modul A viele Annahmen über Modul B macht. Durch Weiterentwicklung werden manche der Annahmen falsch werden. Es entstehen Ripple Effects. Je weniger Annahmen/Abhängigkeiten da sind, desto geringer ist die Wahrscheinlichkeit, dass Ripple Effects auftreten.  Beispiel  ###ToDo: beispiel ® 1&1 Internet AG 2013 42
High Cohesion (HC)  Aussage  Die Bindung in einem Modul sollte stark sein.  Begründung  Eine schwache Bindung würde bedeuten, dass gewisse Teile des Moduls „thematisch“ dort nicht hingehören. Zum einen verschlechtert das die Lesbarkeit. Zum anderen bedeutet das ja auch, dass eine Änderung in dem Modul sich auf Teile auswirken kann, die thematisch gar nicht betroffen sein müssten. Auch das sind Ripple Effects.  Beispiel  ###ToDo: beispiel ® 1&1 Internet AG 2013 43
LC und HC ® 1&1 Internet AG 2013 44
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 45
Entwurfsentscheidungen  Modularisierung  Welche Artefakte, Klassen, Methoden, etc.  Modulkommunikation  Methodenaufrufe: wann, welche Klasse mit welcher anderen  Schnittstellen  Methodensignaturen, Parameter, …  … ® 1&1 Internet AG 2013 46
Masterarbeit ® 1&1 Internet AG 2013 47
Patterns und Pattern Langauges Christopher Alexander: A Pattern Language ® 1&1 Internet AG 2013 48
Neue Idee: Prinzipiensprachen A Principle Language ® 1&1 Internet AG 2013 49
Welche Aspekte sind zu bedenken? Wie findet man passende Prinzipien? ® 1&1 Internet AG 2013 50
OOD Principle Language ® 1&1 Internet AG 2013 51
Beispiel ® 1&1 Internet AG 2013 52
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 53
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 54
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 55
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 56
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 57
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 58
Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 59
Resultat  LC  KISS  RoE  TdA/IE  ML ® 1&1 Internet AG 2013 60
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 61
Das Wiki www.principles-wiki.net ® 1&1 Internet AG 2013 62
Das Wiki ® 1&1 Internet AG 2013 63
Das Große Ganze ® 1&1 Internet AG 2013 64
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 65
Vorteile  Lernen  Entscheiden  Kommunizieren ® 1&1 Internet AG 2013 66
Lernen ® 1&1 Internet AG 2013 67
Lernen ® 1&1 Internet AG 2013 68
Entscheiden ® 1&1 Internet AG 2013 69
Entscheiden ® 1&1 Internet AG 2013 70
Kommunizieren ® 1&1 Internet AG 2013 71
Kommunizieren ® 1&1 Internet AG 2013 72
Kommunikation Prinzipien-Sprachen ® 1&1 Internet AG 2013 73
Fazit  Prinzipien  Sind wiederverwendbare von Erfahrung  Unterscheiden gute von schlechten Lösungen  Prinzipiensprachen  Vernetzen Prinzipien  Zeigen weiterführende Aspekte auf  Bilden ein Vokabular  www.principles-wiki.net ® 1&1 Internet AG 2013 74
Ausblick  Das Wiki wird ständig erweitert und ausgebaut  Weitere  Prinzipien  Prinzipiensprachen  Vernetzung von Patterns mit Prinzipien  Mitarbeit willkommen ® 1&1 Internet AG 2013 75
Ausblick: Ideen  Prinzipiensprachen für  Andere Programmierparadigmen  Prozedurale, funktionale, dynamische, 4GL etc. Programmierung  Andere Abstraktionsstufen  Architektur, Coding, Anforderungsanalyse, …  Andere Arten von Design  GUI Design, Webdesign, Mobile UI Design, …  DB-Entwurf, API Design, Communication Protocol Design, …  Nicht-Funktionale Anforderungen  Security, Performance, Usability, …  Spezielle Domänen  Embedded Systems, Enterprise Information Systems, Spiele, …  Medizin, Finanzen, Automotive, … ® 1&1 Internet AG 2013 76
Zeit für Fragen… Vielen Dank für Ihre Aufmerksamkeit Karriere bei 1&1 Speziell für Entwickler Unternehmen kennenlernen klassisch via jobs.1und1.de Kontaktnetzwerk knüpfen Optimalen Job finden 77
Source Center Wie funktioniert das Source Center?  Einarbeitung (Technologien, Prozesse, Kultur)  Teameinsatz (~6 Monate produktiver Einsatz)  Fach-/Technologische Spezifika kennenlernen  Soziales Netzwerk aufbauen  Standort übergreifender Einsatz möglich (finanziert AG)  Wechsel in dauerhafte Position jederzeit möglich (Gegenseitigkeit) ® 1&1 Internet AG 2013
Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile  Anhang ® 1&1 Internet AG 2013 79
Dependency Inversion ® 1&1 Internet AG 2013 80
Beispiel: Rahmenbedingungen  Rahmenbedingungen:  Eine Software verwendet intern Exceptions  An der Schnittstelle werden aber auch technischen Gründen (REST) Fehlercodes erwartet  Anforderung: Exceptions in HTTP Response Codes übersetzen ® 1&1 Internet AG 2013 81
Beispiel: Lösung 1 – alles fangen public Response doSomethong() { try { … } catch (SomeException e) { return Response.status(NOT_FOUND).build(); } catch (OtherException e) { return Response.status(BAD_REQUEST).build; } } ® 1&1 Internet AG 2013 82
Beispiel: Lösung 2 – Exception Mapper pro Exception public class SomeExceptionMapper implements ExceptionMapper<SomeException> { public Response toResponse(SomeException exception) { return Response.status(NOT_FOUND).build(); } } ® 1&1 Internet AG 2013 83
Beispiel: Lösung 3 – Ein Exception Mapper public class BaseExceptionMapper implements ExceptionMapper<BaseException> { public Response toResponse(BaseException exception) { return Response.status(exception.getStatus()).build(); } } ® 1&1 Internet AG 2013 84
OOD Principle Language ® 1&1 Internet AG 2013 85

Weitere ähnliche Inhalte

PPSX
Assembly language programming
Gaurav Takrani
 
PPT
Sprache und politik
bfnd
 
PPT
Assembly Language Lecture 1
Motaz Saad
 
PPTX
BASIC Programming Language
Jeff Valerio
 
PPTX
Programming language
Makku-Sama
 
PPT
Basic Programming Concept
Cma Mohd
 
PPT
Assembly Language Basics
Education Front
 
PPTX
1&1 KMU Studie
1&1
 
Assembly language programming
Gaurav Takrani
 
Sprache und politik
bfnd
 
Assembly Language Lecture 1
Motaz Saad
 
BASIC Programming Language
Jeff Valerio
 
Programming language
Makku-Sama
 
Basic Programming Concept
Cma Mohd
 
Assembly Language Basics
Education Front
 
1&1 KMU Studie
1&1
 

Mehr von 1&1 (20)

PPTX
Inhalte strukturieren für bessere User Experience und Maschinenlesbarkeit
1&1
 
PPTX
Erfahrungen aus einem Jahr Content Marketing
1&1
 
PPTX
Mehr Sichtbarkeit durch Google News und AMP
1&1
 
PPTX
SEO & Content Marketing entlang der Customer Journey
1&1
 
PPTX
SEO Content: Eine Zeitreise
1&1
 
PPTX
Social Media bei 1&1
1&1
 
PPTX
Secure Software Development Lifecycle
1&1
 
PPTX
Camunda@1&1
1&1
 
PPTX
Design Types
1&1
 
PDF
HostingCon Europe: Grow your hosting business by better serving small businesses
1&1
 
PPTX
1&1 New Hosting Products
1&1
 
PPTX
1&1 Hosting Europe Media Event: Server Update
1&1
 
PPTX
1&1 Hosting Europe Media Event: New Top Level Domains
1&1
 
PPTX
DIY Web Builder: Apps and Social Media
1&1
 
PDF
Passwort-Sicherheit - WEB.DE Studie 2012 (Convios Consulting GmbH)
1&1
 
PDF
Kundenzufriedenheitsoffensive bei 1&1 - mehr als eine Kampagne
1&1
 
PDF
Website-Studie 2012
1&1
 
PDF
Die neuen Features der 1&1 Do-It-Yourself Homepage im Überblick
1&1
 
PDF
IPv6 at 1&1
1&1
 
PDF
Vorteile eines ISP beim Anti-Botnet-Beratungszentrumn
1&1
 
Inhalte strukturieren für bessere User Experience und Maschinenlesbarkeit
1&1
 
Erfahrungen aus einem Jahr Content Marketing
1&1
 
Mehr Sichtbarkeit durch Google News und AMP
1&1
 
SEO & Content Marketing entlang der Customer Journey
1&1
 
SEO Content: Eine Zeitreise
1&1
 
Social Media bei 1&1
1&1
 
Secure Software Development Lifecycle
1&1
 
Camunda@1&1
1&1
 
Design Types
1&1
 
HostingCon Europe: Grow your hosting business by better serving small businesses
1&1
 
1&1 New Hosting Products
1&1
 
1&1 Hosting Europe Media Event: Server Update
1&1
 
1&1 Hosting Europe Media Event: New Top Level Domains
1&1
 
DIY Web Builder: Apps and Social Media
1&1
 
Passwort-Sicherheit - WEB.DE Studie 2012 (Convios Consulting GmbH)
1&1
 
Kundenzufriedenheitsoffensive bei 1&1 - mehr als eine Kampagne
1&1
 
Website-Studie 2012
1&1
 
Die neuen Features der 1&1 Do-It-Yourself Homepage im Überblick
1&1
 
IPv6 at 1&1
1&1
 
Vorteile eines ISP beim Anti-Botnet-Beratungszentrumn
1&1
 
Anzeige

Prinzipiensprachen

  • 2. Organisatorisches  Folien enthalten nur wenig Text  Besser für Präsentation  Zusätzlich ausführlichere Vortragsnotizen online  Die Vortragsnotizen geben nicht notwendigerweise 1:1 den Vortrag wieder  Feedback erwünscht  Bei Fragen  Fragen!  Wenn kurze Antworten möglich sind, gleich  Ansonsten zum Ende eines Kapitels ® 1&1 Internet AG 2013 2
  • 3. Vorstellung – Wer erzählt das hier alles eigentlich?  Christian Rehn, 25 Jahre, Softwareentwickler  Informatikstudium an der TU Kaiserslautern  Seit Mai im 1&1 Source Center  Blog: http://www.christian-rehn.de  Wiki: http://www.principles-wiki.net  E-Mail: christian.rehn@1und1.de ® 1&1 Internet AG 2013 3
  • 4. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 4
  • 5. Geschichte Es war einmal… ® 1&1 Internet AG 2013 5
  • 6. Geschichte QBasic, Delphi, … ® 1&1 Internet AG 2013 6
  • 10. BibDB ® 1&1 Internet AG 2013 10
  • 11. Warum? Was unterscheidet gute Lösungen von schlechten? ® 1&1 Internet AG 2013 11
  • 12. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 12
  • 13. Was unterscheidet gute Lösungen von schlechten?  Bewertung, nicht Generierung von Lösungen  Nicht: „Wie komme ich auf eine Lösung?“  Irgendwelche Lösungen zu finden, ist oft gar nicht das Problem  Sondern: „Wie weiß ich, ob das gut ist?“ ® 1&1 Internet AG 2013 13
  • 14. Es gibt viele Prinzipien ® 1&1 Internet AG 2013 14
  • 15. Prinzip: Definition Ein Prinzip ist eine Daumenregel, die gute von schlechten Lösungen unterscheidet – in Bezug auf einen Entwurfsaspekt. ® 1&1 Internet AG 2013 15
  • 16. Information Hiding/Encapsulation (IH/E) “Objekte sind wie Abwasserleitungen” ® 1&1 Internet AG 2013 16
  • 17. Murphy‘s Law (ML) “Whatever can go wrong, will go wrong” ® 1&1 Internet AG 2013 17
  • 18. Murphy‘s Law (ML) ® 1&1 Internet AG 2013 18
  • 19. Murphy‘s Law (ML) “If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.” ® 1&1 Internet AG 2013 19
  • 20. Murphy‘s Law (ML) “Whatever can go wrong, will go wrong” ® 1&1 Internet AG 2013 20
  • 21. Murphy‘s Law (ML)  Aussage  Alles was schief gehen kann, wird irgendwann schiefgehen. Also ist eine Lösung dann besser, wenn sie weniger Möglichkeiten zulässt, dass etwas schiefgeht.  Begründung  Menschen machen Fehler und das wird sich nie grundlegend ändern. Statistisch gesehen wird also auf lange Sicht, eine Fehler-Möglichkeit auch zu einem Fehler führen.  Beispiel  Date date1 = new Date(2013, 01, 12); ® 1&1 Internet AG 2013 21
  • 22. Murphy‘s Law (ML) “new Date(2013, 01, 12);” ® 1&1 Internet AG 2013 22
  • 23. Keep It Simple Stupid (KISS) ® 1&1 Internet AG 2013 23
  • 24. Keep It Simple Stupid (KISS) “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” – Tony Hoare ® 1&1 Internet AG 2013 24
  • 25. Keep It Simple Stupid (KISS)  Aussage  Einfache Lösungen sind besser als komplizierte.  Begründung  Wenn etwas einfacher ist, kann man es einfacher verstehen und ändern.  Wenn etwas einfacher ist, macht man weniger Fehler.  Beispiel  Eine Lösung ohne komplizierte Sprachfeatures wie polymorphe Enums, innere Klassen und tiefe Vererbungshierarchien, … ® 1&1 Internet AG 2013 25
  • 26. Generalization Principle (GP)  Aussage  Mächtige, allgemein anwendbare Lösungen sind besser als Speziallösungen.  Begründung  Allgemeine Lösungen sind wiederverwendbar  Wenn sich die Anforderungen ändern, muss man spezielle Lösungen eher ändern  Beispiel  Funktionen mit Parametern, wiederverwendbare Klassen, Generics, … ® 1&1 Internet AG 2013 26
  • 28. Beispiel  Anforderung:√2 wird benötigt  Mehrere Möglichkeiten 1. final double SQRT_2 = 1.4142135623730951; 2. double sqrt_2() {…} 3. double sqrt(double r) {…} 4. double power(double base, double exponent) {…} 5. class ComplexPolynomRootCalculator ® 1&1 Internet AG 2013 28
  • 31. Principle of Separate Understandability (PSU)  Aussage  Jedes Modul sollte separat verständlich sein.  Begründung  Andere Module lesen und verstehen zu müssen kostet unnötig Zeit und ist fehleranfällig.  Beispiel  … folgt auf den nächten Folien … ® 1&1 Internet AG 2013 31
  • 32. Principle of Separate Understandability (PSU) // Anforderung: printStatistics('d', 0); // „There are 0 ds“ printStatistics('d', 1); // „There is 1 d“ printStatistics('d', 25); // „There are 25 ds“ ® 1&1 Internet AG 2013 32
  • 33. Principle of Separate Understandability (PSU) private void printStatistics( } else { number = char ch, int count) { String number; String verb; Integer.toString(count); String pluralModifier; verb = "are"; if (count == 0) { pluralModifier = "s"; number = "no"; } verb = "are"; String message = String.format("There %s %s pluralModifier = "s"; %s%s", verb, number, ch, } else if (count == 1) { pluralModifier); number = "1"; verb = "is"; pluralModifier = ""; ® 1&1 Internet AG 2013 System.out.println(message); } 33
  • 34. Principle of Separate Understandability (PSU) class StatisticsMessage { private String number; private String verb; private String pluralModifier; … public String make( char ch, int count) { createMessageParts(count); return String.format( "There %s %s %s%s", verb, number, ch, private void createMessageParts( int count) { if (count == 0) thereAreNoLetters(); else if (count == 1) thereIsOneLetter(); else thereAreManyLetters(count); } private void thereAreNoLetters() { number = "no"; verb = "are"; pluralModifier = "s"; } … pluralModifier); } ® 1&1 Internet AG 2013 34
  • 35. Principle of Separate Understandability (PSU) private String composeStatistics(char candidate, int count) { Number number = requiresPluralForm(count) ? PLURAL : SINGULAR; return "There " + thirdFormOfToBe(number) + " " + countToString(count) + " " + declineLetter(candidate, number)); } ® 1&1 Internet AG 2013 35
  • 36. Principle of Separate Understandability (PSU) private boolean requiresPluralForm(int count) { return count != 1; } private String thirdFormOfToBe(Number number) { return number == SINGULAR ? "is" : "are"; } private String countToString(int count) { return count == 0 ? "no" : Integer.toString(count); } private String declineLetter(char letter, Number number) { return number == SINGULAR ? Character.toString(letter) : letter + "s"; } ® 1&1 Internet AG 2013 36
  • 38. Ripple Effects und Shotgun Surgery ® 1&1 Internet AG 2013 38
  • 39. Kommunikation beschränken ® 1&1 Internet AG 2013 39
  • 40. Bindung und Kopplung  Cohesion/Bindung  Maß für den Zusammenhalt eines Moduls  Coupling/Kopplung  Maß für die Abhängigkeiten zwischen den Modulen ® 1&1 Internet AG 2013 40
  • 41. HC, LC und Abstraktionsstufen ® 1&1 Internet AG 2013 41
  • 42. Low Coupling (LC)  Aussage  Die Kopplung zwischen Modulen sollte lose sein.  Begründung  Eine starke Kopplung zwischen den Modulen A und B bedeutet, dass o.B.d.A. Modul A viele Annahmen über Modul B macht. Durch Weiterentwicklung werden manche der Annahmen falsch werden. Es entstehen Ripple Effects. Je weniger Annahmen/Abhängigkeiten da sind, desto geringer ist die Wahrscheinlichkeit, dass Ripple Effects auftreten.  Beispiel  ###ToDo: beispiel ® 1&1 Internet AG 2013 42
  • 43. High Cohesion (HC)  Aussage  Die Bindung in einem Modul sollte stark sein.  Begründung  Eine schwache Bindung würde bedeuten, dass gewisse Teile des Moduls „thematisch“ dort nicht hingehören. Zum einen verschlechtert das die Lesbarkeit. Zum anderen bedeutet das ja auch, dass eine Änderung in dem Modul sich auf Teile auswirken kann, die thematisch gar nicht betroffen sein müssten. Auch das sind Ripple Effects.  Beispiel  ###ToDo: beispiel ® 1&1 Internet AG 2013 43
  • 44. LC und HC ® 1&1 Internet AG 2013 44
  • 45. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 45
  • 46. Entwurfsentscheidungen  Modularisierung  Welche Artefakte, Klassen, Methoden, etc.  Modulkommunikation  Methodenaufrufe: wann, welche Klasse mit welcher anderen  Schnittstellen  Methodensignaturen, Parameter, …  … ® 1&1 Internet AG 2013 46
  • 48. Patterns und Pattern Langauges Christopher Alexander: A Pattern Language ® 1&1 Internet AG 2013 48
  • 49. Neue Idee: Prinzipiensprachen A Principle Language ® 1&1 Internet AG 2013 49
  • 50. Welche Aspekte sind zu bedenken? Wie findet man passende Prinzipien? ® 1&1 Internet AG 2013 50
  • 51. OOD Principle Language ® 1&1 Internet AG 2013 51
  • 53. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 53
  • 54. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 54
  • 55. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 55
  • 56. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 56
  • 57. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 57
  • 58. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 58
  • 59. Eine Prinzipiensprache navigieren ® 1&1 Internet AG 2013 59
  • 60. Resultat  LC  KISS  RoE  TdA/IE  ML ® 1&1 Internet AG 2013 60
  • 61. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 61
  • 63. Das Wiki ® 1&1 Internet AG 2013 63
  • 64. Das Große Ganze ® 1&1 Internet AG 2013 64
  • 65. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile ® 1&1 Internet AG 2013 65
  • 66. Vorteile  Lernen  Entscheiden  Kommunizieren ® 1&1 Internet AG 2013 66
  • 74. Fazit  Prinzipien  Sind wiederverwendbare von Erfahrung  Unterscheiden gute von schlechten Lösungen  Prinzipiensprachen  Vernetzen Prinzipien  Zeigen weiterführende Aspekte auf  Bilden ein Vokabular  www.principles-wiki.net ® 1&1 Internet AG 2013 74
  • 75. Ausblick  Das Wiki wird ständig erweitert und ausgebaut  Weitere  Prinzipien  Prinzipiensprachen  Vernetzung von Patterns mit Prinzipien  Mitarbeit willkommen ® 1&1 Internet AG 2013 75
  • 76. Ausblick: Ideen  Prinzipiensprachen für  Andere Programmierparadigmen  Prozedurale, funktionale, dynamische, 4GL etc. Programmierung  Andere Abstraktionsstufen  Architektur, Coding, Anforderungsanalyse, …  Andere Arten von Design  GUI Design, Webdesign, Mobile UI Design, …  DB-Entwurf, API Design, Communication Protocol Design, …  Nicht-Funktionale Anforderungen  Security, Performance, Usability, …  Spezielle Domänen  Embedded Systems, Enterprise Information Systems, Spiele, …  Medizin, Finanzen, Automotive, … ® 1&1 Internet AG 2013 76
  • 77. Zeit für Fragen… Vielen Dank für Ihre Aufmerksamkeit Karriere bei 1&1 Speziell für Entwickler Unternehmen kennenlernen klassisch via jobs.1und1.de Kontaktnetzwerk knüpfen Optimalen Job finden 77
  • 78. Source Center Wie funktioniert das Source Center?  Einarbeitung (Technologien, Prozesse, Kultur)  Teameinsatz (~6 Monate produktiver Einsatz)  Fach-/Technologische Spezifika kennenlernen  Soziales Netzwerk aufbauen  Standort übergreifender Einsatz möglich (finanziert AG)  Wechsel in dauerhafte Position jederzeit möglich (Gegenseitigkeit) ® 1&1 Internet AG 2013
  • 79. Agenda  Motivation/Geschichte  Prinzipien  Prinzipiensprachen  Das Wiki  Vorteile  Anhang ® 1&1 Internet AG 2013 79
  • 80. Dependency Inversion ® 1&1 Internet AG 2013 80
  • 81. Beispiel: Rahmenbedingungen  Rahmenbedingungen:  Eine Software verwendet intern Exceptions  An der Schnittstelle werden aber auch technischen Gründen (REST) Fehlercodes erwartet  Anforderung: Exceptions in HTTP Response Codes übersetzen ® 1&1 Internet AG 2013 81
  • 82. Beispiel: Lösung 1 – alles fangen public Response doSomethong() { try { … } catch (SomeException e) { return Response.status(NOT_FOUND).build(); } catch (OtherException e) { return Response.status(BAD_REQUEST).build; } } ® 1&1 Internet AG 2013 82
  • 83. Beispiel: Lösung 2 – Exception Mapper pro Exception public class SomeExceptionMapper implements ExceptionMapper<SomeException> { public Response toResponse(SomeException exception) { return Response.status(NOT_FOUND).build(); } } ® 1&1 Internet AG 2013 83
  • 84. Beispiel: Lösung 3 – Ein Exception Mapper public class BaseExceptionMapper implements ExceptionMapper<BaseException> { public Response toResponse(BaseException exception) { return Response.status(exception.getStatus()).build(); } } ® 1&1 Internet AG 2013 84
  • 85. OOD Principle Language ® 1&1 Internet AG 2013 85