BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENEVA

HAMBURG COPENHAGEN LAUSANNE MUNICH STUTTGART VIENNA ZURICH

Die S.O.L.I.D-Prinzipien

für C# Entwickler

Thomas Claudius Huber@ThomasClaudiusH

Thomas Claudius Huber

Developer Week 2016 - Nürnberg - Thomas Claudius Huber2 22.06.2016

Principal Consultant @ Trivadis AGCloud Solutions

Developer, Trainer, Architect

Microsoft MVP for Windows Development

Spezialisiert in WPF, Angular 2, C#, .NET, Azure

What else:

Pluralsight-Autor, Buchautor

Fussball, Skaten, Fitness, Gitarre

Agenda

Developer Week 2016 - Nürnberg - Thomas Claudius Huber3 22.06.2016

1. Die S.O.L.I.D.-Prinzipien

2. Umsetzung in C#

3. Summary

Developer Week 2016 - Nürnberg - Thomas Claudius Huber4 22.06.2016

1. Die S.O.L.I.D.-Prinzipien

S.O.L.I.D.-Prinzipien

Developer Week 2016 - Nürnberg - Thomas Claudius Huber5 22.06.2016

Fünf Prinzipien für wartbaren Code

Nicht an eine Technologie gebunden

Single

Responsibility

Open /

Closed

Liskov

Substitution

Interface

Segregation

Dependency

Inversion

Wo hat das Ganze seinen Ursprung

Developer Week 2016 - Nürnberg - Thomas Claudius Huber6 22.06.2016

S.O.L.I.D.-Acronym wurde von Michael Feathers eingeführt

– Basierend auf den ersten 5 objektorientierten Prinzipien von Robert C. Martin

Werden die fünf Prinzipien angewendet, soll der Code

wartbarer und leicht erweiterbar sein

Developer Week 2016 - Nürnberg - Thomas Claudius Huber7 22.06.2016

2. Umsetzung in C#

Ein Demo-Projekt

Developer Week 2016 - Nürnberg - Thomas Claudius Huber8 22.06.2016

Ein einfacher File-Reader

Let’s «hack» it down

Demo

Single Responsibility Principle (SRP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber9 22.06.2016

“There is one and only one reason

to change a class”

Demo

Single Responsibility Principle (SRP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber10 22.06.2016

Weitere Beispiele

Single Responsibility Principle (SRP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber11 22.06.2016

Nur eine Verantwortlichkeit

Gilt für alle Objekte: Assemblies, Klassen, Methoden

Sorgt für wartbare, kleine Klassen

Open/Closed Principle (OCP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber12 22.06.2016

“Software entities (classes, modules,

functions, etc.) should be open for

extension, but closed for

modification”

Open/Closed Principle (OCP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber13 22.06.2016

Open for Extension Closed for Modification

Die Klasse kann um neue

Anforderungen erweitert werden

Bestehender Code wird

nicht verändert

Open/Closed Principle (OCP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber14 22.06.2016

Änderungen durch Hinzufügen von neuem Code

Änderungen NICHT durch Änderung von altem Code

Der Schlüssel liegt in der Abstraktion

Demo

Open/Closed Principle (OCP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber15 22.06.2016

Bestehender Code wird nicht geändert

Unit Tests bleiben grün

Manchmal schwierig was virtual ist und was nicht

Liskov Substitution Principle (LSP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber16 22.06.2016

“Objects in a program should be

replaceable with instances of their

subtypes without altering the

correctness of that program”

Liskov Substitution Principle (LSP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber17 22.06.2016

Eine Erweiterung von OCP

Sicherstellen, dass abgeleitete Klassen das Verhalten der

Basisklasse nicht verändern

Demo

Interface Segregation Principle (ISP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber18 22.06.2016

“Clients should not be forced to

depend upon interfaces that they do

not use”

Interface Segregation Principle (ISP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber19 22.06.2016

Grosse Interfaces = mehr Abhängigkeiten

Interface Pollution (Clients müssen Member implementieren,

welche sie nicht brauchen)

Lösung: Keine „fat“ Interfaces, stattdessen viele kleine

Interfaces

Demo

Dependency Inversion Principle (DIP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber20 22.06.2016

“Depend upon Abstractions. Do not

depend upon concretions”

Dependency Inversion Principle (DIP)

Developer Week 2016 - Nürnberg - Thomas Claudius Huber21 22.06.2016

Abstraktion durch Interfaces / abstrakte Basisklassen

Code lässt sich ohne Implementierungen testen

– Mocking von Interfaces

Üblich wird zum Auflösen der Interfaces ein DI-Container

genutzt

Demo

Developer Week 2016 - Nürnberg - Thomas Claudius Huber22 22.06.2016

3. Summary

Anzeichen auf «stinkenden» Code

Developer Week 2016 - Nürnberg - Thomas Claudius Huber23 22.06.2016

If-Statement, welches Typen unterscheidet -> OCP

Interface-Methoden, welche in vielen Fällen nicht

implementiert werden müssen -> ISP

FAT Interfaces -> ISP

Methodennamen wie: UpdateAndSaveCustomer(),

VerifyAndSaveData() -> SRP

Klassennamen wie CustomerManager -> SRP

S.O.L.I.D.-Summary

Developer Week 2016 - Nürnberg - Thomas Claudius Huber24 22.06.2016

Hilft wartbaren Code zu schreiben

Projekte bekommen eine gute Struktur

Es sind lediglich Prinzipien

– Nicht übertreiben.

Fragen?Thomas Claudius Huber

@thomasclaudiush

thomas.huber@trivadis.com

www.thomasclaudiushuber.com

22.06.2016 Developer Week 2016 - Nürnberg - Thomas Claudius Huber25