Objektorienteeritud programmeerimine: liideste mõistmine

Viimati uuendatud nov. 21, 2022

Sisu

Siinkohal ütleksin, et objektorienteeritud programmeerimise mõistmise alused on loodud.

Täpsemalt olen käsitlenud järgmist:

Ja, jah, vaieldakse selle üle, mis on alused (st mõned ei viska polümorfismi segusse, kuigi ma teen). Kuid ülaltoodud neli peaksid andma kindla aluse, millelt jätkata oma objektorienteeritud programmeerimisoskuste arendamist.

Neid on rohkemgi, kuid ma arvan, et need pole nii sügavad, üksikasjalikud või raskesti mõistetavad kui mõned eelnimetatud mõisted. Siis jälle tulevad erinevad asjad teistele kergemini.

Igal juhul on järgmised kaks teemat, millest on oluline aru saada:

Liidesed
Abstraktsioon

Ma räägin igaühest eraldi, kuid veenduge, et olete kõigepealt lugenud põhialuste seeriat, sest ülaltoodud kaks teemat võimaldavad teil neile toetuda ja neid ära kasutada.

Ebamäärane, ma tean, aga lubage mul selgitada ja siis minna sealt edasi.

Liideste mõistmine

Kõige tavalisem liidese määratlus, mida tõenäoliselt kuulete, on see, et tegemist on lepinguga. See pole vale, kuid arvan, et see jätab palju soovida.

Näiteks kui mõtlete lepingutele, mõtlete tõenäoliselt millelegi, mis on väga seotud, palju kõnepruuki, keeruline protsess millegi allkirjastamiseks, kuupäevaks saamiseks, töövalmistamiseks ja nii edasi.

Kuid mis puudutab programmeerimisliidest, siis see pole tegelikult nii. Tegelikult väidan, et liideste määratlemine võib muuta programmeerimise lihtsamaks ja see leevendab palju bürokraatiat, kuna muudab asjad väga mustaks või valgeks, mida midagi peaks rakendama.

Mõni sõna liideste kohta

Meie tööstus kasutab sõna "liides" kahe asja jaoks:

Disainerid ja kasutajad kasutavad mõistet liides, et kirjeldada, mida nad näevad ja kuidas nad rakendusega suhtlevad. See hõlmab selliseid asju nagu nupud, rippmenüüd ja muud elemendid, mida saame puudutada.
Programmeerijad kasutavad seda terminit, et viidata sellele, milliseid funktsioone alamklass peab liidese järgimiseks rakendama. Seda nimetatakse liidese programmeerimiseks.

Viimast selles artiklis käsitletakse. Ja ei, me ei kavatse kasutada tüüpilisi näiteid, nagu programmeerimine loomaliidesele või mis iganes. Selle asemel vaatame seda tegelike koodinäidiste põhjal.

Programmeerimine liidesele

Me defineerime "liidesesse programmeerimist" kui viisi, kuidas saame kirjutada koodi, mis rakendab nimetatud liideses määratletud funktsioonide allkirju.

Aga mis on meetodi allkirjad? Lihtsamalt öeldes hõlmavad meetodi allkirjad:

funktsiooni nimetuse nimi,
argumendid, mida see nõuab,
nähtavuse muutja

Klassi kontekstis näete seda järgmiselt:

<?php

class Cache 
{
  public function set($key, $value) 
  {
    // method implementation
  }
}

Lihtne, eks?

Ülaltoodud koodis näeme, et komplekti funktsioon aktsepteerib kasutatavat võtit ja väärtust ning funktsioonile pääseb juurde iga objekt, millel on klassile viide.

Kuid liidesed võivad ka seda sisaldada. Siiski on hoiatus: liidestel pole meetodi rakendamist.

Nii et selle asemel :

<?php

class Cache 
{
  public function set($key, $value) {
    set_transient($key, $value);
  }
}

Näete seda:

<?php

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

Kuid ülaltoodud koodis on ka paar nüanssi, mida tähele panna.

See kood ei määratle seda klassina. Selle asemel nimetatakse seda liideseks.
Klassi nime ees on i, mis näitab, et tegemist on liidesega. See ei ole nõutav; see on konventsioon.
Meetodil pole rakendust. Sellel pole midagi peale allkirja.

Liidese loomisel ütleme, nagu eespool mainitud, et mis iganes klass seda liidest rakendab, määrab selles sisalduvad meetodid.

Nii et kui peaksime kõik ülaltoodud asjad kokku siduma, näeks lõplik teostus välja järgmine (kuigi ideaaljuhul hoiaksime seda eraldi failides):

<?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);
  }
}

Ja nii sobivad liidesed ja klassid kokku.

See on see?

Lihtsamalt öeldes jah. Kuid oma kogemuse põhjal olen avastanud, et see on midagi enamat kui lihtsalt meetodite määratlemine ja nende rakendamine.

Sageli on lihtne määratleda klasse, seejärel määratleda liides ja seejärel liides rakendada. Aga see on täiesti tagurpidi. Selle asemel peame oma töö üle strateegilisemalt mõtlema.

Selle asemel, et asuda liidesesse, mis eesmärgi täielikult kaotab, peame alustama laialt, et meie klassid saaksid spetsialiseeruda sellele, mida nad teevad, rakendades samal ajal funktsioone, mis on ühised mitte ainult sellele klassile, vaid ka teistele klassidele, mis võivad vajada samu funktsioone.

Ülaltoodud näidet kasutades võib meil olla SimpleCache, TransientCache või mõnda muud tüüpi vahemälu. Olenemata sellest, millist tüüpi vahemälu me rakendame, rakendavad nad liidest ja funktsionaalsus jäetakse liidest rakendava klassi hooleks.

Seega määratleme, milline võib vahemälu kõrgel tasemel välja näha, kuid rakendusklassid määravad täpselt, kuidas need toimivad.

Kui olete WordPressi arendaja ja soovite õppida, kuidas praktilisi objektorienteeritud tehnikaid kasutades rakenduse peale asju ehitada, siis miks mitte saidiga liituda?

: tommcfarlin.com