Olio-ohjelmointi: Käyttöliittymien ymmärtäminen

Viimeisin päivitys marras 21, 2022

Sisältö

Tässä vaiheessa sanoisin, että olio-ohjelmoinnin ymmärtämisen perusta on luotu.

Erityisesti olen käsitellyt:

Ja kyllä, on keskustelua siitä, mikä muodostaa perustan (eli jotkut eivät heitä polymorfismia sekoitukseen, vaikka teenkin). Mutta edellä mainittujen neljän pitäisi tarjota vankka perusta, jolta voit jatkaa olio-ohjelmointitaitosi rakentamista.

On enemmänkin, mutta en usko, että ne ovat niin syviä, yksityiskohtaisia tai vaikeasti ymmärrettäviä kuin jotkut edellä mainituista käsitteistä. Sitten taas eri asiat tulevat toisille helpommin.

Joka tapauksessa seuraavat kaksi aihetta, jotka on tärkeää ymmärtää, ovat:

Liitännät
Abstraktio

Puhun jokaisesta erikseen, mutta varmista, että olet lukenut Fundamentals – sarjan ensin, koska yllä olevat kaksi aihetta antavat sinun luottaa niihin ja hyödyntää niitä.

Epämääräistä, tiedän, mutta anna minun selittää ja sitten mennä sieltä.

Käyttöliittymien ymmärtäminen

Ylivoimaisesti yleisin käyttöliittymän määritelmä, jonka todennäköisesti kuulet, on, että se on sopimus. Tämä ei ole väärin, mutta mielestäni se jättää paljon toivomisen varaa.

Esimerkiksi, kun ajattelet sopimuksia, ajattelet todennäköisesti jotain, joka on hyvin mukana, paljon ammattikieltä, monimutkaista prosessia, jolla jotain allekirjoitetaan, päivätään, valmistetaan työskentelyyn ja niin edelleen.

Mutta mitä tulee ohjelmointirajapintoihin, tämä ei todellakaan pidä paikkaansa. Itse asiassa väittäisin, että rajapintojen määrittäminen voi helpottaa ohjelmointia ja lievittää paljon byrokratiaa, koska se tekee asioista erittäin mustavalkoisia sen suhteen, mitä jotain pitäisi toteuttaa.

Sana "liitännöistä"

Toimialamme käyttää sanaa "käyttöliittymä" kahdelle asialle:

Suunnittelijat ja käyttäjät käyttävät termiä käyttöliittymä kuvaamaan, mitä he näkevät ja kuinka he ovat vuorovaikutuksessa sovelluksen kanssa. Tämä sisältää esimerkiksi painikkeita, avattavia valikoita ja muita elementtejä, joita voimme "koskettaa".
Ohjelmoijat käyttävät termiä viittaamaan siihen, mitä toimintoja alaluokan tulee toteuttaa liittyäkseen rajapintaan. Tätä kutsutaan "ohjelmoimiseksi käyttöliittymään".

Jälkimmäistä käsitellään tässä artikkelissa. Ja ei, emme aio käyttää tyypillisiä esimerkkejä, kuten ohjelmointia Animal – rajapintaan tai mitä tahansa. Sen sijaan tarkastelemme sitä todellisista koodinäytteistä.

Ohjelmointi käyttöliittymään

Määrittelemme "ohjelmoinnin rajapinnalle" tapaksi kirjoittaa koodia, joka toteuttaa mainitussa rajapinnassa määriteltyjen toimintojen allekirjoitukset.

Mutta mitä ovat metodi-allekirjoitukset? Yksinkertaisesti sanottuna menetelmän allekirjoitukset sisältävät:

funktion nimen nimi,
sen vaatimat argumentit,
näkyvyyden muokkaaja

Luokan kontekstissa näet sen seuraavasti:

<?php

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

Helppoa, eikö?

Yllä olevasta koodista voimme nähdä, että set – funktio hyväksyy käytettävän avaimen ja arvon, ja toiminto on käytettävissä millä tahansa objektilla, jolla on viittaus luokkaan.

Mutta käyttöliittymät voivat myös sisältää tämän. Siinä on kuitenkin varoitus: liitännöillä ei ole menetelmätoteutusta.

Joten mieluummin kuin jotain tällaista:

<?php

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

Näet tämän:

<?php

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

Mutta yllä olevassa koodissa on myös pari hienovaraisuutta.

Tämä koodi ei määrittele sitä luokkaksi. Sen sijaan se kutsuu sitä käyttöliittymäksi.
Luokan nimessä on i-kirjain, joka osoittaa, että se on käyttöliittymä. Tätä ei vaadita; se on yleissopimus.
Menetelmällä ei ole toteutusta. Siinä ei ole muuta kuin allekirjoitus.

Kun luomme käyttöliittymän, sanomme, kuten edellä mainittiin, että mikä tahansa luokka toteuttaa rajapinnan, määrittää sen sisältämät menetelmät.

Joten jos yhdistäisimme kaikki yllä näkemämme, lopullinen toteutus näyttäisi tältä ( vaikka mieluiten säilyttäisimme tämän erillisissä tiedostoissa):

<?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 näin käyttöliittymät ja luokat sopivat yhteen.

Se siitä?

Yksinkertaisesti sanottuna kyllä. Mutta kokemukseni mukaan olen huomannut, että siinä on muutakin kuin menetelmien määrittely ja niiden toteuttaminen.

Usein on helppoa määritellä luokat, sitten määritellä käyttöliittymä ja sitten toteuttaa käyttöliittymä. Mutta se on täysin taaksepäin. Sen sijaan meidän on mietittävä työtämme strategisemmin.

Sen sijaan, että tukeutuisimme käyttöliittymään, joka kumoaa tarkoituksen täysin, meidän on aloitettava laajasta, jotta luokkamme voivat erikoistua siihen, mitä he tekevät, samalla kun ne toteuttavat toimintoja, jotka ovat yhteisiä paitsi tälle luokalle myös muille luokille, jotka saattavat tarvita samoja toimintoja.

Yllä olevan esimerkin avulla meillä voi olla SimpleCache, TransientCache tai jokin muu välimuisti. Riippumatta siitä, minkä tyyppistä välimuistia käytämme, he toteuttavat käyttöliittymän, ja toiminnallisuus jätetään rajapinnan toteuttavalle luokalle.

Joten määrittelemme, miltä välimuisti voi näyttää korkealla tasolla, mutta toteutusluokat määrittelevät tarkalleen, kuinka ne toimivat.

Jos olet WordPress-kehittäjä ja haluat oppia rakentamaan asioita sovelluksen päälle käytännöllisillä, oliopohjaisilla tekniikoilla, miksi et liittyisi sivustoon?

: tommcfarlin.com