När en produktlista på en webbplats behöver hålla reda på namn, pris och lagerstatus kan ett vanligt objekt räcka en stund, men logiken växer lätt när varje produkt ska kunna uppdateras på samma sätt. En klass i JavaScript passar ofta när flera objekt ska dela struktur och metoder, men den är inte alltid enklare än en funktion som skapar objekt.
En klass samlar data och beteenden i en återanvändbar modell
- Skapa en instans med nyckelordet
new. - Initiera instansdata i
constructor()eller med klassfält. - Dela metoder mellan instanser via klassens prototyp.
- Skydda intern data med privata fält som börjar med
#. - Välj klass när flera objekt följer samma modell och behöver gemensamma metoder.
En klass blir användbar när objekten följer samma modell
Tänk dig att en webbshop visar flera produkter med namn, pris och lagerstatus. Med en klass kan varje produkt få samma grundform, samtidigt som metoderna för exempelvis prisvisning inte behöver skrivas om för varje objekt.
Jag tycker att klasser fungerar bäst när de uttrycker en tydlig modell i programmet, inte när de bara ger ett objekt ett mer högtidligt namn. Om datan är enkel och saknar egna beteenden kan ett vanligt objekt vara lättare att läsa.
Constructor och new skapar en produktinstans
Metoden constructor() körs när en instans skapas med new. Parametrarna blir egenskaper på just det objektet, medan vanliga metoder i klassen delas mellan instanserna.
class Product {
constructor(name, price, inStock = true) {
this.name = name;
this.price = price;
this.inStock = inStock;
}
displayPrice() {
return `${this.name}: ${this.price} kr`;
}
}
const notebook = new Product("Anteckningsbok", 49);
console.log(notebook.displayPrice());Här kan varje produkt ha ett eget namn och pris, men alla använder samma displayPrice()-metod. En vanlig miss är att försöka anropa Product() utan new; en klass måste instansieras med new, annars uppstår ett fel. MDN:s referens om klasser beskriver även klassfält som ett alternativ när ett startvärde inte behöver komma från konstruktorns argument.
Metoder ligger på prototypen, inte i varje produkt
En detalj som ofta överraskar är att metoder som deklareras direkt i klassen inte kopieras som separata funktioner till varje instans. Instanserna hittar i stället metoden via klassens prototyp, en länkad objektstruktur som JavaScript använder för arv och delat beteende.
Det betyder att notebook.displayPrice och metoden på en annan produktinstans normalt pekar på samma funktion. En pilfunktion som tilldelas som klassfält fungerar annorlunda: då skapas en separat funktion för varje instans, vilket kan vara användbart för vissa återanropsfunktioner men blir onödigt om metoden ska delas.
Privata fält och statiska metoder har olika jobb
Om lagerantalet ska ändras via en metod i stället för att kunna skrivas över fritt, kan ett privat fält börja med tecknet #. Det ger ett faktiskt åtkomstskydd i språket, inte bara en namnkonvention med understreck.
class Product {
#stock;
constructor(name, stock) {
this.name = name;
this.#stock = stock;
}
isAvailable() {
return this.#stock > 0;
}
}Kod utanför klassen kan anropa isAvailable(), men kan inte läsa #stock direkt. Privata fält måste deklareras i klassens kropp, och en underklass kan inte komma åt föräldraklassens privata fält; det är en skillnad som blir viktig när modellen byggs ut. MDN:s dokumentation om privata klasselement förklarar begränsningen.
En static-metod hör däremot till klassen själv, inte till en viss produkt. Den passar exempelvis för en funktion som validerar produktdata innan någon instans skapas; anropa den som Product.validate(data), inte som notebook.validate(data).
Välj klass när gemensamma regler väger tyngre än enkel data
En klass passar när flera objekt delar både struktur och beteenden, till exempel produkter som alla kan kontrollera lagertillgänglighet. För en enda konfigurationspost med några få värden kan ett objekt vara tydligare, och en fabriksfunktion kan passa när objekt ska skapas utan en klasshierarki.
| Situation | Trolig orsak eller följd | Gör så här |
|---|---|---|
| Du har flera likartade instanser med samma metoder | En gemensam modell minskar duplicerad logik | Skapa en klass och håll instansdata i konstruktorn eller klassfält |
| Objektet består av ett fåtal värden utan eget beteende | En klass kan lägga till struktur utan praktisk nytta | Använd ett vanligt objekt |
En metod används som återanropsfunktion och tappar sitt this |
Metodanropets sammanhang följer inte automatiskt med | Bind metoden eller använd ett klassfält med pilfunktion om en instansbunden funktion behövs |
| En underklass behöver läsa ett privat fält från sin förälder | #fält är privat även för underklassen |
Exponera ett avsett skyddat beteende via en metod, eller ompröva klassindelningen |
Arv med extends och super kan återanvända beteende från en basklass, men varje extra nivå gör det svårare att följa var en metod kommer ifrån. Jag skulle välja arv först när underklassen verkligen kan behandlas som samma sorts objekt; annars är separata klasser eller komposition oftast lättare att underhålla.
En liten modell är lättare att hålla begriplig
Börja med en klass när du kan namnge både den återkommande datan och minst ett beteende som hör till varje instans. Lägg till privata fält när andra delar av programmet annars kan skapa ogiltiga tillstånd, och använd statiska metoder för uppgifter som inte kräver en enskild instans.
Om klassen däremot mest innehåller fält utan logik, börja enklare. Den bästa modellen för en produktlista är den som gör det lätt att se vad produkten kan göra och vilka regler som skyddar dess data.