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

Prinzipiensprachen

  • 1.
  • 2.
    Organisatorisches  Folien enthaltennur 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 – Wererzä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.
  • 8.
  • 9.
  • 10.
  • 11.
    Warum? Was unterscheidet guteLö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 guteLö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 vielePrinzipien ® 1&1 Internet AG 2013 14
  • 15.
    Prinzip: Definition Ein Prinzipist 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) “Objektesind wie Abwasserleitungen” ® 1&1 Internet AG 2013 16
  • 17.
    Murphy‘s Law (ML) “Whatevercan 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) “Ifthere’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) “Whatevercan 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) “newDate(2013, 01, 12);” ® 1&1 Internet AG 2013 22
  • 23.
    Keep It SimpleStupid (KISS) ® 1&1 Internet AG 2013 23
  • 24.
    Keep It SimpleStupid (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 SimpleStupid (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.
  • 28.
    Beispiel  Anforderung:√2 wirdbenö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.
  • 30.
  • 31.
    Principle of SeparateUnderstandability (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 SeparateUnderstandability (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 SeparateUnderstandability (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 SeparateUnderstandability (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 SeparateUnderstandability (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 SeparateUnderstandability (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.
  • 38.
    Ripple Effects undShotgun Surgery ® 1&1 Internet AG 2013 38
  • 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 undAbstraktionsstufen ® 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  WelcheArtefakte, Klassen, Methoden, etc.  Modulkommunikation  Methodenaufrufe: wann, welche Klasse mit welcher anderen  Schnittstellen  Methodensignaturen, Parameter, …  … ® 1&1 Internet AG 2013 46
  • 47.
  • 48.
    Patterns und PatternLangauges Christopher Alexander: A Pattern Language ® 1&1 Internet AG 2013 48
  • 49.
    Neue Idee: Prinzipiensprachen APrinciple Language ® 1&1 Internet AG 2013 49
  • 50.
    Welche Aspekte sindzu bedenken? Wie findet man passende Prinzipien? ® 1&1 Internet AG 2013 50
  • 51.
    OOD Principle Language ®1&1 Internet AG 2013 51
  • 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.
  • 63.
    Das Wiki ® 1&1Internet 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.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 73.
  • 74.
    Fazit  Prinzipien  Sindwiederverwendbare 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 Wikiwird ständig erweitert und ausgebaut  Weitere  Prinzipien  Prinzipiensprachen  Vernetzung von Patterns mit Prinzipien  Mitarbeit willkommen ® 1&1 Internet AG 2013 75
  • 76.
    Ausblick: Ideen  Prinzipiensprachenfü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… VielenDank 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 funktioniertdas 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&1Internet 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