Abstrakta klasser, del 2 – Abstrakta klasser och gränssnitt

I förra inlägget i den här serien gick jag igenom:

• grunderna i abstrakta klasser,
• hur man implementerar dem,
• och gav exempel på arbetskoder.

Och även om jag tror att förståelse av abstrakta klasser är nyckeln till att lägga en stark grund för objektorienterad programmering, ser jag ofta att det kan vara förvirrande när det gäller att jämföra dem med gränssnitt och att veta när de ska användas.

Abstrakta klasser och gränssnitt

Så i det här inlägget ska jag dela:

• en snabb uppdatering om vad gränssnitt är,
• vad är abstrakta klasser,
• och sedan hur man vet när man ska använda den ena framför den andra.

Det här borde inte vara en kodningsintensiv artikel, men det borde hjälpa dig att veta när du ska skriva kod av en viss typ för att hjälpa dig att bättre organisera dina projekt.

1 Gränssnitt

Kom ihåg att när det kommer till gränssnitt använder vi också termen "programmering till ett gränssnitt" med tanken att gränssnittet definierar metoderna som en klass måste implementera för att uppfylla "kontraktet" med nämnda gränssnitt.

Koden som användes för att demonstrera ett grundläggande gränssnitt var:

<?php

interface iCache 
{
  public function set($key, $value);
  public function get($key);
  public function has($key);
}

Men kom ihåg att syftet med gränssnittet inte är att definiera efter att koden har skrivits. Istället är det ett verktyg som används för att designa vad klasser ska implementera om de följer ett visst paradigm eller om de kräver en viss uppsättning funktioner.

Det vill säga, om du ska designa en uppsättning klasser som fungerar med cachning, skriver du inte klasserna först. Du skriver gränssnittet först, och sedan implementerar klasserna nämnda gränssnitt.

Tanken är att alla klasser som implementerar gränssnittet kommer garanterat att ha dessa funktioner.

2 abstrakta klasser

Abstrakta klasser, å andra sidan, låter oss göra två saker:

1. implementera funktionalitet som kan användas av underklasser,
2. implementera metodsignaturer som underklasser måste implementera.

Detta kan vara lite inkongruent till en början, men tänk på detta:

När du har en klass av en viss typ som kommer att ha konsekvent funktionalitet oavsett underklass, går funktionaliteten i den abstrakta klassen. När andra metoder behöver ha sin implementering av en metod, då tillhandahåller du helt enkelt metodsignaturen och markerar den som abstrakt.

Här är ett exempel från ett tidigare inlägg:

Detta får oss alla att fånga upp av de tidigare exemplen och de tidigare sakerna vi behöver fokusera på angående gränssnitt och abstrakta klasser, men för vissa ger detta fortfarande inte mycket klarhet.

Specifikt svarar detta fortfarande inte på frågan: Hur bestämmer vi när vi ska använda en abstrakt klass och när vi ska använda ett gränssnitt?

På ytan kan det låta lite förvirrande, men det finns några saker du kan använda för att fatta beslutet.

När använder vi var och en?

Kom ihåg att när det gäller objektorienterad programmering kan vi dela upp det på tre olika sätt:

• Klasser representerar en sak. Du kan betrakta dessa som ett substantiv.
• Attribut eller egenskaper är som adjektiv. De beskriver föremålet eller något föremålet kan hålla.
• Metoder eller funktioner är som verb. De beskriver vad de invänder kan göra.

När det kommer till ett gränssnitt, tänk på vad gränssnittet gör: Det beskriver, utan implementering, vad ett objekt kan göra. Och när det kommer till en abstrakt klass, beskriver den vad ett objekt är under körning.

Med andra ord, en bra tumregel är att om du behöver tillhandahålla en uppsättning beteenden för ett objekt, är ett gränssnitt en väg att gå. Om du behöver beskriva vad ett objekt är, använd då en abstrakt klass.

För abstrakta klasser skulle jag också ta detta ett steg längre och säga att det hjälper att beskriva en basnivå av data som beskriver ett objekt eller vad det kan lagra förutom en basnivå av funktionalitet.

Har du ett exempel?

Som med det mesta av innehållet i vart och ett av dessa inlägg försöker jag ge exempel även om det inte är specifikt gjort i kod. Detta kanske hjälper till att förklara det ännu mer:

• Gränssnitt har ingen implementering. De garanterar bara vad en klass kommer att göra.
• Abstrakta klasser bör ha en basnivå för implementering. Detta bör representera vad en klass kan hålla och göra men inte är komplett. De kräver lite mer implementering från underklassen.

När du arbetar med objektorienterad kod hoppas jag att detta hjälper till att ge några riktlinjer för när du ska använda vad. Om inte, tveka inte att lämna en kommentar (något medlemmar har tillåtelse att göra :).

Dessutom kommer vi att se detta i praktiken när vi kommer till att skriva objektorienterad kod (främst för WordPress, men inte alltid).