Design principer (SOLID + others) Flashcards
Single Responsibility Principle (SRP) A class should have at most one reason to change.
Vad fyller principen för syfte? (X)
Förändringar hålls väl avgränsade, så om funktionalitet behöver ändras minskas risken för sammanblandning (robust). Detta gör även klassen lättare att testa separat från annan funktionalitet (testing), samt att
all kod som rör ett visst ansvarsområde finns på ett enda ställe (easy access).
Varför är det bra att följa den? (X)
Det är enklare att förstå, testa och felsöka en klass som har ett väl avgränsat ansvarsområde. Dessutom kan man ändra i klassen utan att oroa sig för att det påverkar andra delar.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: En klass BankAccount som hanterar uttag, insättning och saldoändring pga aktuell sparränta. Här finns tre anledningar till förändring.
Följer: Vi delar upp klassen ovan i AccountWithdraw , AccountDeposit och AccountInterest .
Open-Closed Principle (OCP)
Software modules should be open for extension, but closed for modification.
Vad fyller principen för syfte? (X)
Att skriva kod där ny funktionalitet enkelt kan läggas till (open for extension) samtidigt som så mycket som möjligt av existerande kod kan lämnas orörd (closed for modification).
Varför är det bra att följa den? (X)
Koden blir maintainable och extendable.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: Det finns ett switch-statement i koden som måste ändras varje gång man lägger till eller ändrar ett menyalternativ i programmet. Den är inte stängd för modifikation.
Följer: Man skriver robust kod från start med intentionen att ingen ska behöva gå in och ändra den i efterhand.
Liskov Substitution Principle (LSP) (X) Beskriver när arv bör och inte bör användas.
Vad fyller principen för syfte? (X)
Den förtydligar hur en arvstruktur ska se ut (IS-A förhållande), samt sätter upp riktlinjer för när det är lämpligt att faktiskt använda sig av arv. Exempelvis ska subklasser lägga till extra beteenden / beräkningar, de ska inte ändra befintliga beteenden / beräkningar från superklassen.
Varför är det bra att följa den? (X)
Det blir en tydlig struktur vilket gör koden mer lättbegriplig samtidigt som man slipper oväntade beteenden som annars kan uppstå.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
- Bryter: Human är en subklass till Dog (bryter mot IS-A), eller att Square är en subklass till Reqtangle. När vi använder metoden setWidth i Square kommer både width och height ändras (för att det är en fyrkant), här får vi ett beteende vi inte förväntar oss då det bryter mot superklassens beteende.
- Följer: Car ärver av Vehicle . Det är ett IS-A-förhållande, vi behöver inte använda metoder som bryter mot Vehicle ‘s beteende, och vi kan utöka beteendet med metoder som är specifika för Car .
Interface Segregation Principle (ISP)
No client should be forced to depend on methods it does not use.
Vad fyller principen för syfte? (X)
Genom att bryta ut större (fat) interfaces i flera mindre, behöver klienter inte implementera dummy-metoder som de inte ens använder. Fungerar som SRP, fast för interfaces.
Varför är det bra att följa den? (X)
Man slipper onödig kod och man slipper även skriva om koden när en metod, som man inte ens använder, byter signatur (!).
Ge något konkret exempel på
hur man bryter mot, eller följer principen.
Bryter: Ha ett fat interface som innehåller flera olika beteenden. T.ex. ett interface GenerateReport som innehåller två metoder, generateExcel och generatePdf. Klienter som endast vill generera exceldokument tvingas ändå lägga till metoden generatePdf.
Följer: Ha många små interfaces som endast hanterar sitt eget beteende. I exemplet ovan kan man bryta ut interfacet GenerateReport till två olika interfaces.
Dependency Inversion Principle (DIP) Depend on abstraction, not on concrete implementations.
Vad fyller principen för syfte? (X)
1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.
Vi vill skapa så få och lösa beroenden som möjligt, samt att dessa beroenden är avsiktliga.
Genom att använda supertyper istället för subtyper kan vi minska beroendet av en specifik klass.
Varför är det bra att följa den? (X)
Vi får kod med låg coupling och mer flexibilitet.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: Man skapar en superklass som har starka beroenden med sina subklasser. Det orsakar stelhet och koden blir jobbig att ändra.
Följer: Subklasser skapas för att passa superklassen, och därför behöver superklassen inte ändras när vi lägger till eller ändrar i subklasserna.
Observer-pattern or bridge
Command-Query Separation
En metod ska antingen ha sidoeffekter (en mutator) eller returnera ett värde (en accessor), inte båda. Asking a question should not change the answer.
Vad fyller principen för syfte? (X)
Man ska kunna anropa en query-metod (metod med returtyp) utan att oroa sig för att programmets tillstånd ändras. Här är det viktigt att ha koll på sina sidoeffekter.
Varför är det bra att följa den? (X)
Man slipper bli överraskad av oväntade beteenden.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: Metoden returnEvenNumbers tar emot en array, modifierar samma array och returnerar den. Följer: Metoden returnEvenNumbers tar emot en array, skapar en kopia av arrayen (Mutate-by-copy), modifierar kopian och returnerar den.
Composition Over Inheritance
Favor composition over inheritance.
Vad fyller principen för syfte? (X)
Den ger lösare beroenden och mer robust kod jämfört med arv (där subklassen helt kan sluta fungera om det sker en förändring i superklassen). Koden blir även mer flexibel då Java inte stödjer multipla implementationsarv, och det är även möjligt att återanvända kod där arv inte är lämpligt.
Varför är det bra att följa den? (X)
Det som står ovan.
Ge något konkret exempel på hur man bryter mot, eller följer principen. Bryter: Koden fokuserar på arv, inte delegering.
Följer: Koden fokuserar på delegering, inte arv.
STATE-PATTERN is great example
High Cohesion, Low Coupling
- Cohesion: Mått på den inre sammanhållningen i en modul (metod, klass…).
- Coupling: Mått på hur starkt beroendet är mellan två moduler.
Vad fyller principen för syfte? (X)
- Cohesion: Vi eftersträvar high cohesion, dvs när samtliga komponenter i modulen samverkar för att lösa sitt ansvarsområde utan att behöva andra moduler. Det ger varje modul ett väl avgränsat ansvarsområde.
- Coupling: Vi eftersträvar low coupling, dvs när moduler är så oberoende av varandra som möjligt. Detta möjliggör en flexibel och modulär design.
Varför är det bra att följa den? (X)
High cohesion och low coupling lägger grunden för återanvändning av komponenter.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: Klass 1 och klass 2 håller objekt av varandra, samt att metod A i klass 1 och metod B i klass 2 refererar till den andra klassen.
Följer: Metoderna A och B beror endast på komponenter i den egna klassen för att lösa sin uppgift, och endast en av klasserna får hålla ett objekt av den andra (fast bara om det är nödvändigt).
Law of Demeter (LoD) / Principle of Least Knowledge
Don’t talk to strangers.
Vad fyller principen för syfte? (X)
Vi undviker att introducera beroenden genom att: en klass bara ska känna till sina närmsta “vänner” (ofrånkomliga beroenden), och klassen ska inte heller anropa metoder hos andra än sina vänner.
Varför är det bra att följa den? (X)
LoD åstadkommer kod med låg coupling, är testbar och som kan återanvändas.
Ge något konkret exempel på hur man bryter mot, eller följer principen. Bryter: Vi introducerar metoder som agerar på externa objekt.
T.ex. objectA.getObjectB().getObjectC().doSomething();
Följer: Vi introducerar metoder som agerar på interna objekt, istället för generiska getters. T.ex. objectA.doSomething();
Separation of Concern (SoC)
“The SoC, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of.” – Edsger W. Dijkstra
Vad fyller principen för syfte? (X)
Att separera ett program i distinkta sektioner så att varje sektion hanterar sitt eget ansvarsområde / logik. Detta kan göras på hög och låg nivå. På hög nivå kan vi bryta ut ett program i sektioner som UI, företagslogik, användarlogik och databasen. MVC är ett bra exempel på SoC där man delar upp programmet i en Modell, View och Controller. På låg nivå fungerar SoC som SRP, fast SoC hanterar mer än bara klassen.
Varför är det bra att följa den? (X)
Då kan flera programmerare jobba på olika sektioner isolerat från varandra, koden blir reuseable, enklare att underhålla, testa, med mera.
Ge något konkret exempel på hur man bryter mot, eller följer principen.
Bryter: Vi har MVC-logik utan att de är uppdelade var för sig. Vi kan även ha en metod som hanterar inloggning för företagskunder OCH privatkunder.
Följer: Vi använder och delar upp MVC som det är tänkt. Vi har även två separata metoder för inloggning, en för företagskunder och en för privatkunder.
