Hvad er klassehierarki?
Et klasseshierarki, også kaldet en klassetakonomi, er en gruppe af beslægtede klasser, der er forbundet via arv for at gøre lignende ting. Toppen af hierarkiet kan være en enkelt baseklasse, hvorfra alle andre klasser under det er afledt, eller hierarkiet kan have flere baseklasser, hvis funktionaliteter flettes sammen senere i en eller flere afledte klasser. Forholdene mellem klasserne kan illustreres som træer, og hvert mindre træ inden for den store taksonomi kan også betragtes som et hierarki.
Ikke alle klassehierarkier kan have flere rødder, og strukturen i ethvert klassehierarki afhænger stort set af det sprog, det er skrevet i. C ++ tillader flere arver, så komplekse hierarkier kan bygges med flere rødder og flere træer, der smelter sammen. Java® er på den anden side begrænset til en enkelt arv, så dens klasseforhold er normalt enklere, bygget som relativt selvstændige træer med en enkelt rod. Grænsefladearv kan tilføje en vis kompleksitet til et klasseshierarki i Java®, men grænseflader næsten aldrig påberåbes i en så kompleks ramme, at det ville være som at flette træer sammen.
Komponenterne i et klasseshierarki kan variere i type og funktion, så længe sprogets regler altid følges med hensyn til arv. Klasser i et hierarki kan være offentlige, beskyttede, abstrakte, konkrete eller virtuelle. Grænseflader, globale funktioner og venner kan også bruges. Afhængigt af computersproget kan nogle af disse typer give dem bedre mulighed for arv end andre. Generelt er hierarkier meget fleksible og kan bruges på mange måder til mange formål.
Der er ingen hårde regler for, hvor bestemte typer klasser skal placeres i et hierarki. Enhver klasse kan tænkes at være en af de ovennævnte typer. Generelt bør de sidste klasser i hierarkiet, der ikke har afledte klasser under dem, være offentlige og konkrete. Da rent abstrakte klassehierarkier også kan eksistere, er dette imidlertid bare en tommelfingerregel.
Selvom et klassehierarki kan være et nyttigt værktøj til at organisere kode og indkapsle funktionalitet, kan der være tidspunkter, hvor det at dybe for dybt ned i et hierarki faktisk kan forveksle koden i stedet for at afklare den og gøre det lettere at vedligeholde. At opbygge et robust forhold mellem mange klasser kræver en vis mængde fremsyn; mens det i første omgang kan være lettere at opdele kode i mange små stykker, kan disse små stykker blive vanskeligere at håndtere senere. Når det er bygget korrekt, hjælper et klassehierarki både udviklere og brugere med at bestemme, hvordan klasser fungerer. Hvis det er bygget uden vedligeholdelse og klarhed i tankerne, kan de mange arveniveauer være forvirrende at se tilbage på og forstå.