Konstruera en klass enligt designmönstret decorator...

Uppgift:

Jag vill få lite hjälp med tolkningen av denna uppgift och bolla mina tankar gällande ett par frågor som uppstått.

Min tolkning av uppgiften:
En klass (CounterIterator) skall skapas som kommer vara själva Decoratorklassen i detta mönster. CounterIterator implementerar gränssnittet “Iterator” som är själva komponenten som skall utökas med en ytterligare funktion, nämligen metoden getCount().  

Fråga 1:
Bör man förutsätta att ConcreteComponent (se klassdiagram nr 2 längst ner) finns med, men ej nämns? Eller kan jag fortfarande tillämpa Decoratormönstret utan en ConcreteComponent?

Syftet med Decorator är ju att lägga till extra ansvar/funktionalitet till ett objekt dynamiskt och dessa objekt som dekoreras med ytterligare funktionalitet är väl just en eller flera ConcreteComponent-objekt? Om ingen ConcreteComponent finns med så kommer väl CounterIterator både fylla funktion som Decorator och ConcreteComponent? Kan i så fall strukturen se ut på följande vis:

Fråga 2:

Förutsatt att min tolkning är “korrekt” så funderar jag på relationen mellan Iterator och CounterIterator. “Bör” relationen vara av ägande-typ (aggregation eller composition) eller av känner-till-typ? (association). Iterator är väl bara ett gränssnitt som skall finnas där för att dra nytta av, men samtidigt så kan väl inte CounterIterator klara sig utan gränssnittet då den är beroende av metoderna? Jag kanske rör till det nu…