Als Entwickler haben wir gute Ideen und weniger gute. Manchmal ist es aber gar nicht so einfach, diese voneinander zu unterscheiden. Oder wir haben das Gefühl, dass etwas gut oder schlecht ist, haben aber Schwierigkeiten, dieses zu erklären. Hier helfen Softwareentwicklungsprinzipien. Diese in schlaue Sprüche gegossene Entwicklererfahrung hilft, Argumente zu finden und zu kommunizieren. Darüber hinaus lassen sich Prinzipien untereinander verknüpfen. Dabei entstehen Prinzipiensprachen, die helfen, Entwurfsentscheidungen systematisch zu treffen und zu begründen. Im Rahmen einer Gastvorlesung an der Uni Stuttgart wurden Prinzipien und Prinzipiensprachen vorgestellt und an Beispielen erläutert.

1. Prinzipiensprachen
Christian Rehn – 1&1 Source Center
1

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

7. Geschichte
® 1&1 Internet AG 2013
7

8. Geschichte
® 1&1 Internet AG 2013
8

9. Geschichte
® 1&1 Internet AG 2013
9

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

27. Problem
Prinzipien
widersprechen einander
® 1&1 Internet AG 2013
27

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

29. Pareto-Optimum
® 1&1 Internet AG 2013
29

30. Tradeoff
Tradeoff
® 1&1 Internet AG 2013
30

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

37. Module Communication
Module Communication
® 1&1 Internet AG 2013
37

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

47. Masterarbeit
® 1&1 Internet AG 2013
47

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

52. Beispiel
® 1&1 Internet AG 2013
52

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

62. Das Wiki
www.principles-wiki.net
® 1&1 Internet AG 2013
62

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

67. Lernen
® 1&1 Internet AG 2013
67

68. Lernen
® 1&1 Internet AG 2013
68

69. Entscheiden
® 1&1 Internet AG 2013
69

70. Entscheiden
® 1&1 Internet AG 2013
70

71. Kommunizieren
® 1&1 Internet AG 2013
71

72. Kommunizieren
® 1&1 Internet AG 2013
72

73. Kommunikation
Prinzipien-Sprachen
® 1&1 Internet AG 2013
73

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