Prinzipiensprachen

transcript

Prinzipiensprachen

Christian Rehn – 1&1 Source Center

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: christian.rehn@1und1.de

Agenda

Motivation/Geschichte

Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Geschichte

Es war einmal…

Geschichte

QBasic, Delphi, …

Geschichte

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)

“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

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

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

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

TdA/IE

Agenda

Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Das Wiki

www.principles-wiki.net

Das Wiki

Das Große Ganze

Agenda

Prinzipien

Prinzipiensprachen

Das Wiki

Vorteile

Lernen

Entscheiden

Kommunizieren

Lernen

Entscheiden

Kommunizieren

Kommunikation

Prinzipien-Sprachen

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…

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

} 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

Prinzipiensprachen

Documents