Objektorienterad programmering: Förstå gränssnitt
Vid det här laget skulle jag säga att grunden för att förstå objektorienterad programmering har lagts.
Specifikt har jag täckt:
Och, ja, det finns en viss debatt om vad som utgör grunden (det vill säga, vissa kastar inte in polymorfism i mixen även om jag gör det). Men de fyra ovanstående borde ge en solid grund för att fortsätta bygga dina objektorienterade programmeringsfärdigheter.
Det finns fler, men jag tror inte att de är lika djupa, detaljerade eller svåra att förstå som några av de tidigare nämnda begreppen. Återigen, olika saker blir lättare för andra.
I vilket fall som helst är följande två ämnen som är viktiga att förstå:
- Gränssnitt
- Abstraktion
Jag kommer att prata om varje separat men se till att du har läst Fundamentals -serien först eftersom ovanstående två ämnen gör att du kan lita på dem och dra nytta av dem.
Vague, jag vet, men låt mig förklara och sedan gå därifrån.
Förstå gränssnitt
Den absolut vanligaste definitionen av ett gränssnitt som du sannolikt kommer att höra är att det är ett kontrakt. Detta är inte fel, men jag tycker att det lämnar mycket övrigt att önska.
Till exempel, när du tänker på kontrakt tänker du förmodligen på något som är väldigt involverat, mycket jargong, en komplicerad process att få något undertecknat, daterat, redo att arbeta och göra så vidare.
Men när det kommer till programmeringsgränssnitt är detta verkligen inte fallet. Faktum är att jag skulle hävda att definition av gränssnitt kan göra programmering enklare och det minskar mycket byråkrati eftersom det gör saker väldigt svarta eller vita om vad något ska implementera.
Ett ord om "gränssnitt"
Vår bransch använder ordet "gränssnitt" för två saker:
- Designers och användare använder termen gränssnitt för att beskriva vad de ser och hur de interagerar med applikationen. Detta inkluderar saker som knappar, rullgardinsmenyer och andra element som vi kan "röra".
- Programmerare använder termen för att referera till vilka funktioner en underklass måste implementera för att följa ett gränssnitt. Detta kallas "programmering till ett gränssnitt".
Det senare är vad som kommer att diskuteras i den här artikeln. Och nej, vi kommer inte att använda typiska exempel som programmering till ett djurgränssnitt eller vad som helst. Istället kommer vi att titta på att göra det från faktiska kodexempel.
Programmering till ett gränssnitt
Vi definierar "programmering till ett gränssnitt" som ett sätt för oss att skriva kod som implementerar signaturerna för funktioner definierade i nämnda gränssnitt.
Men vad är metodsignaturer? Enkelt uttryckt inkluderar metodsignaturer:
- namnet på namnet på funktionen,
- argumenten som krävs,
- synlighetsmodifieraren
I samband med en klass kommer du att se det så här:
<?php
class Cache
{
public function set($key, $value)
{
// method implementation
}
}
Lätt, eller hur?
I koden ovan kan vi se att set -funktionen accepterar en nyckel och ett värde som kommer att användas och funktionen är tillgänglig för alla objekt som har en referens till klassen.
Men gränssnitt kan också innehålla detta. Det finns dock en varning: Gränssnitt har ingen metodimplementering.
Så hellre än något sånt här:
<?php
class Cache
{
public function set($key, $value) {
set_transient($key, $value);
}
}
Du kommer att se detta:
<?php
interface iCache
{
public function set($key, $value);
public function get($key);
public function has($key);
}
Men det finns också ett par subtiliteter att notera i koden ovan.
- Den här koden definierar den inte som en klass. Istället kallar det det ett gränssnitt.
- Klassnamnet har ett ‚i‘ prefix för att indikera att det är ett gränssnitt. Detta krävs inte; det är en konvention.
- Metoden har ingen implementering. Den har inget annat än en signatur.
När vi skapar ett gränssnitt säger vi, som nämnts ovan, att vilken klass som än implementerar gränssnittet kommer att definiera metoderna som det inkluderar.
Så om vi skulle knyta ihop allt som vi har sett ovan, skulle den slutliga implementeringen se ut så här (även om vi helst skulle behålla detta i separata filer):
<?php
interface iCache {
public function set($key, $value);
public function get($key);
public function has($key);
}
public class SimpleCache implemnents iCache
{
public function set($key, $value)
{
set_transient($key, $value, DAY_IN_SECONDS);
}
public function get($key)
{
if (!$this->has($key))
{
return false;
}
return get_transient($key);
}
public function has($key)
{
return false !== get_transient($key);
}
}
Och det är så gränssnitt och klasser passar ihop.
Det är allt?
Enkelt uttryckt, ja. Men enligt min erfarenhet har jag funnit att det är mer än att bara definiera metoderna och implementera dem.
Ofta är det lätt att definiera klasser, sedan definiera gränssnittet och sedan implementera gränssnittet. Men det är helt bakvänt. Istället måste vi tänka mer strategiskt kring vårt arbete.
Istället för att backa in i ett gränssnitt, som helt motverkar syftet, måste vi börja brett så att våra klasser kan specialisera sig på vad de gör samtidigt som de implementerar funktionalitet som inte bara är gemensam för den klassen utan andra klasser som kan behöva samma funktionalitet.
Med exemplet ovan kan vi ha en SimpleCache, en TransientCache eller någon annan typ av cache. Oavsett vilken typ av cache vi implementerar kommer de att implementera gränssnittet, och funktionaliteten kommer att överlåtas till klassen som implementerar gränssnittet.
Så vi definierar hur en cache kan se ut på en hög nivå, men de implementerande klasserna kommer att definiera exakt hur de fungerar.
Om du är en WordPress-utvecklare och vill lära dig hur du bygger saker ovanpå applikationen med hjälp av praktiska, objektorienterade tekniker, varför inte gå med på webbplatsen?