Is-a er et forhold av type — modellert med inheritance (en ). er et forhold av — modellert med (en ). Å velge det rette er en kjernebeslutning i modelleringen.
Is-a er et forhold av type — modellert med inheritance (en ). er et forhold av — modellert med (en ). Å velge det rette er en kjernebeslutning i modelleringen.
CarVehicleCarEngine// IS-A → inheritance
class Vehicle { void move() {} }
class Car extends Vehicle { } // a Car IS A Vehicle
// HAS-A → composition
class Engine { void start() {} }
class Car2 {
private Engine engine = new Engine(); // a Car HAS AN Engine
void start() { engine.start(); } // delegate to the part
}
Spør deg selv: "Er X en slags Y, eller har X en Y?"
A Dog IS-A Animal → inheritance ✅
A Car HAS-A Engine → composition ✅
A Square IS-A Shape → inheritance ✅
A Manager HAS Employees → composition (a list) ✅
A Stack HAS-A list (not IS-A) → composition (see earlier pitfall) ✅
Mennesker griper til inheritance for å gjenbruke kode, selv når forholdet egentlig er has-a. Hvis du aldri ville erstattet subklassen med basen overalt, er det sannsynligvis ikke is-a — bruk composition.
Denne distinksjonen er den praktiske beslutningsregelen bak "foretrekk composition over inheritance": velg forholdet som er sant, ikke det som sparer noen få linjer.
Å få det riktig holder hierarkier grunnleggende og ærlige, og det forhindrer Liskov-brudd der en "subtype" ikke kan erstatte sin forelder.