Alla Design mönster Flashcards
Template Method Pattern (behave)
2 fördelar
VAD
Man har en abstrakt superklass som sedan är specifik för varje implementering av subklass.
NÄR
När kod är till stora delar gemensam, men beror på en liten del som inte är gemensam.
HUR
Bryt ut det som är gemensamt i en abstrakt klass. I denna klass finns en template method som består av massa metodanrop som bildar en algoritm. Låt det som inte är gemensamt representeras av en abstrakt metod dvs som måste skrivas över i subklasserna. Använd hooks i superklassen.
LÖSER DESIGNPROBLEM
- Bättre code reuse trots att koden kan skilja sig åt lite.
- Lätt struktur för att utöka programmet.
Strategy Pattern (behave) (primärt 1 fördel)
VAD
Det är ett behavioral pattern som tillåter algoritmer att variera oberoende från klienterna som använder det.
NÄR
Man använder Strategy när man vill kunna ändra implementationen av en algoritm vid runtime utan att orsaka high cohesion. När det finns olika sätt att utföra liknande typer av uppdrag. När man behöver använda en av flera beteenden dynamiskt.
HUR
Skapa ett interface med metoderna som representerar variationen. Använd dessa metoder i den generiska algoritmen. Definiera konkreta strategier/beteenden som separata klasser som implementerar interfacet. Och skicka dessa till den generiska algoritmen som nödvändigt.
LÖSER DESIGNPROBLEM
Enkelt att lägga till funktionalitet (strategier) men svårt att ändra dem. Gör det enklare att följa en av de viktigare strategier inom OOP, open closed principle.
State Pattern (behave) (1 case specific + 2 generell)
VAD
Ett design pattern som tillåter ett objekt att ändra sitt beteende när dess tillstånd ändras.
NÄR
Vi använder State när ett objekt kan variera ur ett finit antal tillstånd under runtime.
HUR
Definiera ett interface med metoder som representerar variationen. Använd dessa metoder i objektet genom att delegera in dem från interfacet. Definiera sedan konkreta “state”-klasser som implementerar interfacet, använd sedan dessa internt i objektet efter behov.
LÖSER DESIGNPROBLEM
- Endast ett objekt krävs, istället för flera olika. Change during runtime.
- Single Responsibility Principle. Organize the code related to particular states into separate classes.
- Open/Closed Principle. Introduce new states without changing existing state classes or the context.
Observer Pattern (behave) (1 CaseS. + 1 generella fördelar)
VAD
Det är ett design pattern i vilket ett objekt, kallad observable, har en lista med observers som meddelar dem automatiskt när ett tillstånd ändras.
NÄR
När man vill lyssna på ett objekt och hur det förändras istället för att fråga hela tiden.
HUR
Man definierar ett Observer interface där det finns en notify/update metod. Delegerar in interfacet i en klass Observable där det finns metoder för lägg till, ta bort, och notify. Denna klass skickar uppdateringar. Sen så låter man de som vill implementera detta göra detta samt registrera sig för att lyssna.
LÖSER DESIGNPROBLEM
- “ett- till många” beroende mellan objekt kan definieras utan att göra objekt “tightly coupled”.
- Man får alltså lösare beroenden. Man följer dependency inversion principle bättre. Det är också en viktig del i MVC struktur.
Chain of Responsibility Pattern (behave)
2 case specific benefits
VAD
Detta är ett pattern som skickar data till ett objekt och om inte det objektet kan använda den datan så skickar den vidare detta till ett annat objekt som kan ha nytta tills någon har.
NÄR
När man vill undvika beroenden, från det objekt som skickar metod-anropet, till alla de objekt som skulle kunna hantera anropet.
HUR
Man kan definiera ett interface och delegera in interfacet i sig själv. I interfacet finns metoder för vad som ska utföras men även också en “nextChain”. Sen finns klasser som implementerar interfacet och provar att utföra uppgiften eller hänvisar till nextChain som skickar vidare till nästa objekt.
LÖSER DESIGNPROBLEM
Man undviker beroenden från det objekt som skickar anropet till de som väljer ifall de vill hantera det eller inte. Man vill att det ska vara möjligt att mer än en motagare ska kunna behndla ett “request”.
Iterator Pattern (behave) (1 caseS. + 2 generell fördel)
VAD
Iterator är ett design pattern som ger ett likartat sätt att traversera olika samlingar av objekt oberoende av objektets typ.
NÄR
När man vill traversera genom en samling, oberoende av vilken typ objekten i fråga är. Samt när man vill utföra liknande handlingar på en samling, för att på så sätt undvika kod duplicering.
HUR
Skapa ett interface “Iterable”, där “Iterator” ur standardbiblioteket delegeras in genom att skapa en iterator. Delegera in Iterator i varje datainsamling och låt dessa implementera Iterable.
LÖSER DESIGNPROBLEM
- (You can iterate over the same collection in parallel because each iterator object contains its own iteration state.)
- Single Responsibility Principle. You can clean up the client code and the collections by extracting bulky traversal algorithms into separate classes.
- Open/Closed Principle. You can implement new types of collections and iterators and pass them to existing code without breaking anything.
Factory Pattern (creational) (1 caseS. + 2 generella fördelar)
VAD
En Factory Method är en (oftast) statisk metod som abstraherar beteendet hos ne eller flera konkreta konstruktorer. “Att ha en smart konstruktor”.
NÄR
- När man vill gömma konkreta val av datarepresentation och konstruktorer.
- När man vill kunna skapa instanser av objekt vid runtime.
HUR
Man definierar ett gränssnitt/abstrakt klass för att skapa ett objekt, men låter subklasser välja vilken klass man vill instantiera. (factory-metoden är oftast statisk)
LÖSER DESIGNPROBLEM
- You avoid tight coupling between the creator and the concrete products.
- Single Responsibility Principle. You can move the product creation code into one place in the program, making the code easier to support.
- Open/Closed Principle. You can introduce new types of products into the program without breaking existing client code.
Singleton Pattern (creational) (1 caseS. + 2 fördelar)
VAD
Ett design pattern som är beroende av sig själv och således bara går att skapa en gång.
NÄR
Används när man vill vara säker på att det bara skapas en instans av ett objekt.
HUR
Instansiera klassen i sig själv och gör konstruktorn privat. Returnera sedan den instansen i en statisk metod. För att sedan få tillgång till instansen kallar man på den statiska metoden.
LÖSER DESIGNPROBLEM
- Enkelt att modifiera objekt utan att behöva ändra på flera ställen.
- Man löser problemet om hur antalet av instanser kan begränsas.
- Man får ett tydligt program i och med att man bara har en instans av klassen.
(förhindrar dessutom konflikter när flera anropar samma instans samtidigt.)
Bridge Pattern (structural) (1 caseS. + 3 mer generella fördelar)
VAD
lets you split a large class or a set of closely related classes into two separate hierarchies—abstraction and implementation—which can be developed independently of each other.
NÄR
När ett objekt är sammansatt av olika komponenter som varierar oberoende av objektet själv.
HUR
Skapa ett interface av aspektet av objekt som varierar. Implementera detta interface i klasser som beskriver variationen. Delegera in interfacet i klassen med objektet. Ex bil: interface motor. Motor implementeras av v6,v4,v8. Motorn delegeras in i bilen för att få funktionalitet genom komposition.
LÖSER DESIGNPROBLEM
- Hiding: The client code works with high-level abstractions. It isn’t exposed to the platform details.
- Composition hellre än arv då vi delegerar in en komponent i klienten via vårt interface.
- Open/Closed Principle. You can introduce new abstractions and implementations independently from each other.
- Single Responsibility Principle. You can focus on high-level logic in the abstraction and on platform details in the implementation.
Decorator Pattern (structural) (1 mer caseS. + 2 generell fördel)
VAD
Ett pattern som tillåter oss att ändra ett objekt dynamiskt.
NÄR
När vi vill ha förmågan av arv med subklasser men vill kunna ändra funktionalitet under runtime.
HUR
Definiera ett interface med metoder. Skapa en klass med den grundläggande funktionaliteten som implementerar interfacet. Skapa en abstrakt klass som implementerar interfacet och delegera även in interfacet. Skapa subklasser till denna klass som beskriver de olika “decorators” man kan lägga till.
LÖSER DESIGNPROBLEM
- Ansvar kan läggas till och tas bort dynamiskt från objekt under runtime.
- Bättre extensibility då man enkelt kan lägga till “wrappers” (dekoratorer) till objekt utan att behöva ändra grundläggande funktionalitet.
- Single Responsibility Principle. You can divide a monolithic class that implements many possible variants of behavior into several smaller classes.
Adapter Pattern (structural) (primärt 1 generell fördel )
VAD
Ett sätt att låta inkompatibla klasser arbeta tillsammans genom att förändra gränssnittet till något som förväntas av klienterna.
NÄR
När vi har två klasser som är inkompatibla med varandra men vi behöver att de ska kunna fungera tillsammans
HUR
Man skapar alltså ett gränssnitt som passar bättre in till klienten mha en Adapter-klass som exponerar den underliggande klassen på ett annorlunda sätt. Vår Adapter klass implementerar interfacet, vi delegerar in Adaptee i vår Adapter (det som vi vill ändra för klienten). Vi delegerar sedan in interfacet i klienten.
LÖSER DESIGNPROBLEM
Man får bättre code-reuse eftersom man använder den underliggande klassens funktionalitet men kan förändra dess exponering.
Composite (stuctural)
1 caseS. + 1 (3) generella fördelar
VAD
Ett sätt att beskriva en grupp av objekt som att det vore en(1) instans av ett objekt. Man kan få ett slutresultat som en hierarki mha composite pattern.
NÄR
När man vill ha en datatyp som ser ut som ett träd. När man vill behandla en grupp av objekt som man behandlar ett enskilt objekt.
HUR
Definera ett interface eller abstrakt klass (Component) som representerar en basklass eller interface. Definera en “Composite”som representerar en sammansatt klass. Composite klassen implementerar component klassen så man kan skicka en composite till en metod som förväntar sig en component. Definera leaf som är slutet på heirarkin som representeras av konkreta primitiva objekt, leaf implementerar också component.
LÖSER DESIGNPROBLEM
- Man kan behandla en grupp av objekt som ett objekt.
(- Information hiding, man vet inte om man hanterar en grupp av objekt eller ett objekt.
- Separation of concern eftersom man delegerar ut beteenden till andra klasser som man inte behöver veta hur de är implementerade.)
- Open/Closed Principle. You can introduce new element types into the app without breaking the existing code.
Facade Pattern (structural) (1 CaseS.)
VAD
Ett Pattern som gör det mljligt att gömma komplexitet ut mot klient genom att definera en facadeklass som ger ett enklare interaface.
NÄR
Bra när vill gömma sådant som en klient inte behöver veta.
HUR
Dölj intern komplexitet och representation genom ett väldefinierat gränssnitt. Detta gränssnitt tillhandahålls av ett objekt som interagerar med klienten, och ibland även ett antal associerade interfaces.
LÖSER DESIGNPROBLEM
- You can isolate your code from the complexity of a subsystem.(info-hiding?).
Module Pattern (structural) (primärt 2 enkla fördelar)
VAD
Att gruppera liknande element som exempelvis klasser och metoder, som används globalt, till en gemensam enhet. Det syftar till att skapa sammanhängande enheter på högre nivå än e.g. klasser.
(En tolkning är att det inte är Module Pattern ”på riktigt” om man inte har en klass som representerar ”modulen”, dvs en klass som inrymmer hela beteendet.)
NÄR
När vi vill ha en tydligare struktur i ett program.
HUR
Hur man använder det är att man har olika packages för olika funktionaliteter.
LÖSER DESIGNPROBLEM
-Maintainability. C
- Clearity and cohesion.
MVC Pattern (structural) (4 generella fördelar )
VAD
MVC är ett arkiteturellt mönster inom mjukvaruutveckling uppdelat i ett Modell, Vy och en kontroller.
NÄR
När vi har ett program som bearbetar både logic och grafik.
HUR
Model har all data och funktionalitet, denna kommunicerar endast med kontrollern.
Vy representerar data som den får av modellen genom att lyssna efter uppdateringar från modellen via kontrollern.
Kontrollern hanterar kommunikationen via vyn och modellen.
LÖSER DESIGNPROBLEM
- Vi får high cohesion med logisk uppdelning av ansvar mellan MVC-delarna.
- Low coupling då vår model enkelt kommunicerar med grafiken via kontrollern.
-SRP/maintain: Vi får bättre maintainability då vi har en tydligt uppdelning av ansvar mellan klasserna.
