| Excerpt |
|---|
De fleste programmer vil bestå av mange klasser, som det vil lages mange instanser av ved kjøring. Disse instansene vil være koblet sammen i et nettverk (også kalt graf) og begreper som tilstand og oppførsel kan generaliseres til å dekke også strukturer av objekter, ikke bare enkeltobjekter. |
Det finnes hovedsaklig to grunner til å lage strukturer av objekter:
- Objektstrukturer er en naturlig representasjon av verden rundt oss og dermed også dataene i en applikasjon. F.eks. vil et familietre inneholde et hierarki av objekter, med koblinger for familieforhold som giftemål/partnerskap og foreldr/barn. Dette er såkalte data- eller tilstandsorienterte klasser.
- Mange programmer inneholder så mye funksjonalitet at en er nødt til å dele det opp i mindre, funksjonelle enheter for å få ned kompleksiteten og fordele kodingen på flere utviklere. Ved objektorientert programmering er disse funksjonelle enhetene klasser som er koblet sammen i strukturer ut fra hvordan de bruker hverandre. F.eks. vil en bruke egne objekter for å håndtere lagring i databaser og kommunikasjon over nett. Dette er såkalte tjenesteorienterte objekter.
For begge disse typene vil en typisk beskrive slike strukturer med f.eks. UML sin klassediagramtype, og alle programmerere må kunne "oversette" slike diagrammer til kode, dvs. vite hvordan UML sine klasse- og assosiasjonsbegreper realiseres i et objektorientert språk som Java.