Dette klassediagrammet illustrerer forholdet mellom grensesnittetene StringGrid og StringGridIterator og klassen StringGridImpl. StringGridImpl inneholder begge 0, 1 eller flere String-objekter. StringGrid deklarerer metoder som StringGridImpl må implementere, og som gir tilgang til String-objektene den inneholder. StringGridIterator implementerer Iterator<String> og må derfor implementere hasNext() og next(). Den har en assosiasjon til en StringGrid og hasNext()- og next()-metodene brukes for å iterere over String-objektene som det assosierte StringGrid-objektet inneholder. Internt bruker StringGridIterator-objekter row- og column-attributtene for å holde rede på hvilket String-objekt som neste kall til next() skal returnere. hasNext() må bruke row og column og StringGrid-objektet sine getRowCount()- og getColumnCount()-metoder for å si om iterasjonen er ferdig, og next() må bruke row og column og StringGrid-objektet sin getElement(int, int)-metode for å få tak i riktig String-objekt. Hvert kall til next() må dessuten øke column og evt. row (og nullstille column) slik at iterasjonen går forover og til neste linje. Her er det ikke tatt hensyn til rowMajor-logikken, som oppgaven etterspør, men det endrer ikke så mye, kun hvilken av column og row som økes først. |
Dette objekttilstandsdiagrammet viser en objektstruktur med et CardDeck-objekt, som inneholder tre Card-objekter, og hvordan et (og samme) CardContainerIterator utvikler seg over tid gjennom en iterasjon over Card-objektene som CardDeck-objektet inneholder, altså #card1, #card2 og #card3. Vi ser at CardContainerIterator-objektet hele tiden er koblet til samme CardDeck-objekt og at det eneste som endrer seg er pos-attributet, som går gjennom rekka 0, 1, 2 og stopper på 3 (siden 3 >= antall kort). Merk at i dette eksemplet er CardContainerIterator-objektet koblet til et CardDeck-objekt, men at det godt kunne vært et CardHand-objekt eller hvilken som helst instans av en klasse som implementerer CardContainer.
|