Rita ett klassdiagram som beskriver designmönstret Decorator
Uppgift:
Rita ett klassdiagram som beskriver designmönstret Decorator.
Min fråga:
Jag har studerat olika typer av klassdiagram av detta designmönster och dom skiljer sig åt på vissa ställen. Speciellt relationen mellan gränssnittet och decorator-klassen. Har hittat olika exempel som antingen använder Aggregation, Komposition eller Association mellan dessa två klasser. Dessutom finns exempel där relationen antingen är enkelriktad eller oriktad. När man skall lösa en sådan uppgift så finns det väl ingen entydig lösning på uppgiften? (Se de 4 olika klassdiagram nedan av Decorator). Det beror väl på vilket problem man ställs inför? I uppgiften beskrivs ju inget direkt scenario typ som att använda designmönstret för att använda till att dekorera pizzor, tårtor, java.io-klasser etc.
Håller med dig att det valda klassdiagrammet beror av vad som ska lösas.
Rekommenderad läsning är "Design Patterns - Elements Of Reusable Object-Oriented Software". Där beskrivs Decorator bl a med aggregation.
Lindehaven skrev:Håller med dig att det valda klassdiagrammet beror av vad som ska lösas.
Rekommenderad läsning är "Design Patterns - Elements Of Reusable Object-Oriented Software". Där beskrivs Decorator bl a med aggregation.
Tack för boktipset. Den känner jag till och har läst lite i. Här är svaret från facit:
Själva syftet med detta mönster är väl att kunna addera tillägg till en eller flera "default-klasser". Dvs klasser som har någon form av grund som man kan dekorera med ytterligare saker. Exempelvis en vegetarisk pizza har pizzadeg, ost och kanske lite lök och kan slås ihop till en defaultklass som kan liknas med Class_1 ovan. En köttpizza kan motsvara Class_n med en annan uppsättning standardegenskaper. För att kunna göra tillägg (dekorera pizzorna) så är det väl subklasser till Decorator-klassen som motsvarar dessa tillägg? Dvs om jag vill kunna lägga till sallad på vissa pizzor så skapar jag subklassen Sallad som ärver av Decorator-klassen? Funderar lite på varför inte någon subklass är utritad i facit då den väl utgör en viktig funktion av mönstret?
Svårt att svara på varför "facit" endast visar en klass och inte det mer verklighetsnära med subklasser. Om du läser vidare i "Design Patterns..." så skriver författarna att en vanlig konsekvens är just det att det kan bli ganska många små subklasser till Decorator.
Men principiellt räcker en Decorator-klass för en sorts "dekoration", exvis sallad, så "facit" är rätt. Jag skriver "facit" inom citatntecken eftersom det sällan (aldrig?) finns endast ett svar eller en lösning.
Lindehaven skrev:Svårt att svara på varför "facit" endast visar en klass och inte det mer verklighetsnära med subklasser. Om du läser vidare i "Design Patterns..." så skriver författarna att en vanlig konsekvens är just det att det kan bli ganska många små subklasser till Decorator.
Men principiellt räcker en Decorator-klass för en sorts "dekoration", exvis sallad, så "facit" är rätt. Jag skriver "facit" inom citatntecken eftersom det sällan (aldrig?) finns endast ett svar eller en lösning.
Jo det har jag läst, men tänkte mest att kanske en subklass kunde ritas ut för att beskriva Decorator lite tydligare.
Nu vet jag i alla fall att det sällan finns endast ett svar eller en lösning på en sådan fråga.
