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 objektgraf, og begreper som tilstand og oppførsel kan generaliseres til å dekke objektgrafer, ikke bare enkeltobjekter.

Det finnes hovedsaklig to grunner til å lage strukturer av objekter:

  1. 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 foreldre/barn. Dette er såkalte data- eller tilstandsorienterte klasser.

  2. 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 gjerne ha egne objekter som håndterer lagring i databaser og kommunikasjon over nett, som brukes av andre deler av programmet. Dette er såkalte tjenesteorienterte objekter.

I de fleste applikasjoner vil begge disse grunnene for oppdeling i flere klasser være relevante, dvs. en vil ha strukturer av både data- og tjenesteorienterte objekter. Og selv for de minste applikasjonene er det vanlig å i det minste ha en hovedprogramklasse, som håndterer kommunikasjonen med brukeren, og en klasse som håndterer den underliggende logikken og tilbyr dette som en tjeneste til hovedprogramklassen. Se Memory-eksempel versjon 1 for et enkelt eksempel på dette.

Uansett grunnen for å dele et program opp i flere klasser, så vil en typisk beskrive slike strukturer med f.eks. UML sin klassediagramtype. 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.