SOLID principles voor ObjectOriented Design Best practices voor

SOLID principles voor Object-Oriented Design Best practices voor het ontwerpen en coderen van flexibele, losgekoppelde systemen die beter te onderhouden zijn en adaptieve code oplevert.

Javi Kroonenburg • Senior. Net Developer @Ordina • >10 jaar ervaring met. Net/C# (weinig Java ervaring ) • Student Informatica @OU

Wat is SOLID? • Opgesteld door Robert C. Martin (Uncle Bob) in 2000 • Vijftal principes/adviezen voor het ontwerpen van OO-software • SOLID acroniem ingevoerd door Michael Feathers. • Afgelopen decennium verder uitgewerkt en ook opgemerkt door het bedrijfsleven.

Waarom SOLID • Nastreven van een laag-koppelingsgehalte tussen de software componenten (orthogonale componenten). • Kleine onafhankelijke modules die met elkaar werken. • Flexibele codebase • Snel inspelen op veranderingen en nieuwe functionaliteit • Beter testbare en onderhoudbare code. • Makkelijker uitbreidbare code. • Leesbaarheid

De Solid Principles • SRP: The Single Responsibility Principle • OCP: The Open/Closed Principle • LSP: The Liskov Substitution Principle • ISP: The Interface Segregation Principle • DIP: The Dependency Inversion Principle

Coderen tegen abstracties. • Programmeer tegen abstracties i. p. v. concrete implementaties ‘Loose Coupling’ • Veranderingen sneller door te voeren • Polymorfisme benutten! • Niet doorslaan in het aanbrengen van abstracties! • De SOLID principes gebruiken o. a. ‘design patterns’ om hun doel te bereiken. • Patterns: Adapter, Decorator, Composite, Strategy, Template, Factory

Non-SOLID code:

Single Responsibility Principle • Modules, classes en methods dienen enkel één verantwoordelijkheid te hebben. • Of: een module, class of method mag maar één reden hebben om te veranderen. • Modules, classes en methods met meerdere verantwoordelijkheden dienen te worden opgedeeld in kleinere componenten • Verantwoordelijkheden dienen te worden weg gedelegeerd achter abstracties (Interfaces)

Open/Closed Principle Software entities should be open for extension, but closed for modification (Bertrand Mayer, 1988). Closed for modification: Productie code niet aanpassen! Open voor extension: Productie code uitbreiden voor nieuwe functionaliteit. Gebruik Abstracties (Interfaces) Extension points: Implementation Inheritance. Interface Inheritance. Design Patterns: Decorator, Template

Liskov Substitution Principle • Als S een subtype is van T, dan kun je objecten van het type T vervangen door objecten van het type S, zonder dat de applicatie breekt (Barbara Liskov, 1988). • Sub types mogen niet het gedrag van de Parent type veranderen. • Clients mogen niet het verschil merken tussen een Parent en een Child Type. technische interpretatie: • Pre- en Post. Condities, Constraints. • Co-variantie in return Types van methods, Contra-variantie in method parameters, Invarianties respecteren

LSP: Vierkant/Rechthoek probleem

Interface Segregation Principle • Client willen we enkel functies aanbieden die hij nodig heeft. • Opsplitsen van Monolithische Interfaces in kleinere modulaire interfaces. • Voorkomen van extra compilatie slag, bij veranderen van code die de afnemer niet gebruikt.

Multi Client voorbeeld

Dependency Inversion Principle • High level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details. • Classes krijgen hun (abstracte) dependencies aangeleverd via de constructor. • Geen new() keywords in classes (behalve Factory classes). • Dependency Injection. • Unit-testen wordt makkelijker. • Het zijn de veranderlijke delen van de code base waarop we dit principe willen toepassen.

Dependency injection:

Tot slot • • Codeer zoveel mogelijk tegen Interfaces aan. SOLID maakt het mogelijk snel in te spelen op veranderingen. Composition over inheritance. Praktijk leert dat we nog steeds veel veranderingen aanbrengen in bestaande code.