Dekoratör (designmönster)

Inom objekt-orienterad programmering är dekoratör ett designmönster som låter beteenden läggas till i ett individuellt objekt, antingen statiskt eller dynamiskt, utan att beteendet för andra objekt från samma klass påverkas.^[1] Dekoratörmönstret är oftast användbart för att hålla fast vid programmeringsprincipen Single Responsibility Principle, då det låter funktionalitet delas upp mellan klasser med unika områden av intresse.^[2]

Syfte

Dekoratör kan användas för att statiskt utvidga (dekorera) funktionaliteten för ett valt objekt, eller i en del fall när programmet körs, oberoende av andra förekomster av samma klass, förutsatt att en del grundarbete görs när den skrivs. Detta kan åstadkommas genom att designa en ny dekoratörklass som omhöljer originalklassen. Denna inslagning kan uppnås genom följande sekvens av steg:

Gör en underklass av den ursprungliga klassen "Component" till en "Decorator" (se UML-diagrammet);
Lägg till en Component-pekare som en variabel i klassen Decorator;
Skicka en Component till konstruktorn för Decorator för att initiera Component-pekaren;
Omdirigera alla "Component"-metoder till "Component"-pekarna i dekoratörklassen; och
Skriv över alla Component-metoder vars metoders beteende behöver modifieras i klassen ConcreteDecorator.

Detta mönster är designat så att flera dekoratörer kan läggas ovanpå varandra och lägga till en ny funktionalitet till de överskrivna metoderna varje gång.

Observera att dekoratörer och det ursprungliga klassobjektet delar en gemensamt grupp funktioner. I det föregående diagrammet fanns metoden "operation()" tillgänglig i både de dekorerade och odekorerade versionerna.

Dekorationsfunktionerna (t.ex. metoder, egenskaper eller andra medlemmar) definieras vanligtvis av ett gränssnitt, mixin eller klassarv som delas av dekoratörerna och det dekorerade objektet. I det föregående exemplet ärver klassen "Component" från både "ConcreteComponent" och underklasserna som ärver från "Decorator".

Dekoratörmönstret är ett alternativ till arv. Arv lägger till beteende vid kompilering och ändringen påverkar alla förekomster av originalklassen; dekorering kan tillhandahålla nytt beteende för valda objekt när koden körs.

Ett exempel är en applikation som ämnar att skicka notiser. Då kan den abstrakta dekoratör-klassen byggas på med en ny subklass för varje plattform notisen ska skickas till (e.g. SMS, mejl, LinkedIn). Det underlättar skapandet av original-objektet. När originalobjektet skapas så "dekoreras" det med en ny notisklass för varje önskvärd plattform ^[3]

{{ Decorator sms = new smsDecotrator() Decorator slack = new slackDecorator(sms) Decorator linkedIn = new linkedInDecorator(slack) }}

Se även

Referenser

Den här artikeln är helt eller delvis baserad på material från engelskspråkiga Wikipedia.

^ Gamma, Erich (1995). Design Patterns. Reading, MA: Addison-Wesley Publishing Co, Inc. Sid. 175ff. ISBN 0-201-63361-2.
^ ”How to Implement a Decorator Pattern”. Arkiverad från originalet den 7 juli 2015. https://web.archive.org/web/20150707165957/http://sam-burns.co.uk/57/how-to-implement-a-decorator-pattern/.
^ https://refactoring.guru/design-patterns/decorator

[1] Gamma, Erich (1995). Design Patterns. Reading, MA: Addison-Wesley Publishing Co, Inc. Sid. 175ff. ISBN 0-201-63361-2.

[2] ”How to Implement a Decorator Pattern”. Arkiverad från originalet den 7 juli 2015. https://web.archive.org/web/20150707165957/http://sam-burns.co.uk/57/how-to-implement-a-decorator-pattern/.

[3] ttps://refactoring.guru/design-patterns/decorator

[1]

[2]

[3]