Prinzipiensprachen

Prinzipiensprachen

Christian Rehn – 1&1 Source Center

1

Organisatorisches

Folien enthalten nur wenig TextBesser für PräsentationZusätzlich ausführlichere Vortragsnotizen onlineDie Vortragsnotizen geben nicht notwendigerweise 1:1 den Vortrag wieder

Feedback erwünscht

Bei FragenFragen!Wenn kurze Antworten möglich sind, gleichAnsonsten 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: [email protected]


Agenda


Motivation/Geschichte

Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Geschichte


Es war einmal…

Geschichte


QBasic, Delphi, …

Geschichte


Geschichte


Geschichte


BibDB


Warum?


Was unterscheidet gute Lösungen von schlechten?

Agenda



Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Was unterscheidet gute Lösungen von schlechten?

Bewertung, nicht Generierung von LösungenNicht: „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?“


Es gibt viele Prinzipien


Prinzip: Definition


Ein Prinzip ist eine Daumenregel, die gute von schlechten Lösungen

unterscheidet – in Bezug auf einen Entwurfsaspekt.

Information Hiding/Encapsulation (IH/E)


“Objekte sind wie Abwasserleitungen”

Murphy‘s Law (ML)


“Whatever can go wrong, will go wrong”

Murphy‘s Law (ML)


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.”

Murphy‘s Law (ML)


“Whatever can go wrong, will go wrong”

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ündungMenschen 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);


Murphy‘s Law (ML)


“new Date(2013, 01, 12);”

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


Aussage Einfache Lösungen sind besser als komplizierte.

BegründungWenn 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, …


Generalization Principle (GP)

Aussage Mächtige, allgemein anwendbare Lösungen sind besser als

Speziallösungen.

BegründungAllgemeine Lösungen sind wiederverwendbarWenn sich die Anforderungen ändern, muss man spezielle Lösungen eher

ändern

Beispiel Funktionen mit Parametern, wiederverwendbare Klassen, Generics, …


Problem


Prinzipien widersprechen einander

Beispiel

Anforderung:√2 wird benötigt

Mehrere Möglichkeiten1.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


Pareto-Optimum


Tradeoff


Tradeoff

Principle of Separate Understandability (PSU)

Aussage Jedes Modul sollte separat verständlich sein.

BegründungAndere Module lesen und verstehen zu müssen kostet unnötig Zeit und ist

fehleranfällig.

Beispiel… folgt auf den nächten Folien …



// Anforderung:

printStatistics('d', 0); // „There are 0 ds“

printStatistics('d', 1); // „There is 1 d“

printStatistics('d', 25); // „There are 25 ds“



private void printStatistics(

char ch, int count) {

String number; String verb;

String pluralModifier;

if (count == 0) {

number = "no";

verb = "are";

pluralModifier = "s";

} else if (count == 1) {

number = "1";

verb = "is";

pluralModifier = "";


} else {

number =

Integer.toString(count);

verb = "are";

pluralModifier = "s";

}

String message =

String.format("There %s %s %s

%s", verb, number, ch,

pluralModifier);

System.out.println(message);

}


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,

pluralModifier);

}


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"; }

…


private String composeStatistics(char candidate, int count) {

Number number = requiresPluralForm(count) ?

PLURAL : SINGULAR;

return "There "

+ thirdFormOfToBe(number) + " "

+ countToString(count) + " "

+ declineLetter(candidate, number));

}



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";

}


Module Communication


Module Communication

Ripple Effects und Shotgun Surgery


Kommunikation beschränken


Bindung und Kopplung

Cohesion/BindungMaß für den Zusammenhalt eines Moduls

Coupling/KopplungMaß für die Abhängigkeiten zwischen den Modulen


HC, LC und Abstraktionsstufen


Low Coupling (LC)


Aussage Die Kopplung zwischen Modulen sollte lose sein.

BegründungEine 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

High Cohesion (HC)


Aussage Die Bindung in einem Modul sollte stark sein.

BegründungEine 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

LC und HC


Agenda



Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Entwurfsentscheidungen

Modularisierung Welche Artefakte, Klassen, Methoden, etc.

Modulkommunikation Methodenaufrufe: wann, welche Klasse mit welcher anderen

SchnittstellenMethodensignaturen, Parameter, …

…


Masterarbeit


Patterns und Pattern Langauges


Christopher Alexander:

A Pattern Language

Neue Idee: Prinzipiensprachen


A Principle Language

Welche Aspekte sind zu bedenken?


Wie findet man passende Prinzipien?

OOD Principle Language


Beispiel


Eine Prinzipiensprache navigieren














Resultat

LC

KISS

RoE

TdA/IE

ML


Agenda



Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Das Wiki


www.principles-wiki.net

Das Wiki


Das Große Ganze


Agenda



Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Vorteile

Lernen

Entscheiden

Kommunizieren


Lernen


Lernen


Entscheiden


Entscheiden


Kommunizieren


Kommunizieren


Kommunikation


Prinzipien-Sprachen

Fazit

PrinzipienSind wiederverwendbare von ErfahrungUnterscheiden gute von schlechten Lösungen

Prinzipiensprachen Vernetzen PrinzipienZeigen weiterführende Aspekte aufBilden ein Vokabular

www.principles-wiki.net


Ausblick

Das Wiki wird ständig erweitert und ausgebaut

Weitere Prinzipien Prinzipiensprachen

Vernetzung von Patterns mit Prinzipien

Mitarbeit willkommen


Ausblick: Ideen

Prinzipiensprachen fürAndere Programmierparadigmen

Prozedurale, funktionale, dynamische, 4GL etc. Programmierung

Andere AbstraktionsstufenArchitektur, Coding, Anforderungsanalyse, …

Andere Arten von DesignGUI Design, Webdesign, Mobile UI Design, …DB-Entwurf, API Design, Communication Protocol Design, …

Nicht-Funktionale AnforderungenSecurity, Performance, Usability, …

Spezielle DomänenEmbedded Systems, Enterprise Information Systems, Spiele, …Medizin, Finanzen, Automotive, …


Vielen Dank für Ihre Aufmerksamkeit

Zeit für Fragen…

77

klassisch viajobs.1und1.de

Karriere bei 1&1

Unternehmen kennenlernen

Kontaktnetzwerk knüpfen

Optimalen Job finden

Speziell für Entwickler

Source Center

® 1&1 Internet AG 2013

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)

Agenda



Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Anhang

Dependency Inversion


Beispiel: Rahmenbedingungen

Rahmenbedingungen:Eine Software verwendet intern ExceptionsAn der Schnittstelle werden aber auch technischen Gründen (REST)

Fehlercodes erwartetAnforderung: Exceptions in HTTP Response Codes übersetzen


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();

}

}


Beispiel: Lösung 3 – Ein Exception Mapper

public class BaseExceptionMapper implements

ExceptionMapper<BaseException> {

public Response toResponse(BaseException exception) {

return Response.status(exception.getStatus()).build();

}

}


OOD Principle Language


Date post:	19-Jun-2015
Category:	Documents
Upload:	11-internet-ag
View:	212 times
Download:	0 times

Prinzipiensprachen

Documents