Tarkastellaan polymorfismia syvällisesti

Kun aloitin tämän sarjan, puhuin olio-ohjelmoinnin neljästä pilarista. Jokainen näistä aiheista on lueteltu ja linkitetty alla.

1. Abstraktio
2. Kapselointi
3. Perintö
4. Polymorfismi

Tässä vaiheessa haluaisin yleensä siirtyä seuraavaan aiheeseen. Ennen kuin teen niin, haluaisin kuitenkin viettää vielä yhden postauksen polymorfismin käsitteen tutkimiseen.

Tähän mennessä urallani olen nähnyt harvojen aiheiden antavan olio-ohjelmointiin perehtyville enemmän hämmennystä ja ongelmia kuin polymorfismi. Joten haluaisin keskustella siitä hieman syvällisemmin olioohjelmoinnin yhteydessä ja minkä tahansa tietyn kehyksen tai sovelluksen (kuten WordPressin) ulkopuolella.

Tässä viestissä teen nopean katsauksen siihen, mitä olemme keskustelleet tähän mennessä, ja hyppään sitten takaisin polymorfismiin.

Polymorfismi perusteellisesti

Ensinnäkin, kuten mainittiin, haluan nopeasti käydä läpi, mitä tähän mennessä on keskusteltu, varsinkin jos olet peitellyt mitään aiemmista viesteistä.

Älä huoli: mikään alla olevasta ei muutu koodiksi. Sen sijaan se yksinkertaisesti määrittelee käyttämämme termit, jotta sinulla on jonkinlainen käsitys siitä, mihin viittaan, kun näet sanan esiintyvän tässä sarjassa.

Abstraktio

Abstraktoimme idean jostakin luokaksi. Sen sijaan aiomme ottaa ideoita heidän luokkiinsa. Ja tässä on keskeinen ajatus: Luokan tulee edustaa substantiivia.

Kapselointi

Kapselointi on oikeastaan ​​vain "iso" sana, joka viittaa ajatukseen vastuunsa hallinnasta (tai tietojensa seuraamisesta).

Perintö

Perinnöllä tarkoitetaan ajatusta, että yksi luokka, vaikka sillä on oma toteutus, kirjaimellisesti perii ominaisuudet, funktiot ja yleisen toteutuksen emoluokalta.

Polymorfismi

Polymorfismin avulla voimme viitata yhden tyypin luokkaan, kun se voidaan julistaa toiseksi tyypiksi.

Näin sanottuna mielestäni asiat voivat olla hieman monimutkaisempia. Aiemmissa viesteissä olen antanut useita erilaisia ​​koodiesimerkkejä (ja kehotan sinua katsomaan niitä taaksepäin).

Mutta tämänpäiväisessä viestissä yritän tutkia ideaa hieman tarkemmin sekä selityksessä että koodissa.

Perinnön suhteen

Jos se ei ole ilmeistä tässä vaiheessa, polymorfismi liittyy vahvasti periytymiseen. Ajattele asiaa näin: Jos yksi luokka perii ominaisuudet ja menetelmät toiselta luokalta, se voi "seistä paikallaan" emoluokan.

Tämä tarkoittaa, että jos sinulla on jokin sisältöluokka ja sitten kaksi alaluokkaa, joista toinen on viesti ja toinen sivu, voit luoda luokan käyttämällä Sisältöviittaustyyppi.t

Mutta ajon aikana se on itse asiassa Post – tyyppinen esiintymä. Käydä järkeen? Tässä esimerkkinä koodia.

Aluksi aloitamme sisältöluokan määrittämisellä :

<?php
class Content {

   protected $title;

   protected $content;

   protected $metadata;

   public function __construct()
   {
     $this->title = "Hello World!";
     $this->content = "This is a sample piece of content.";
     $this->metadata = "<This is the metadata of the post.>";
   }

   public function getTitle()
   {
     return $this->title;
   }

   public function getContent()
   {
     return $this->content;
   }

   public function getMetadata()
   {
     return $this->metadata;
   }
 }

Siinä on yleiset ominaisuudet, joita olet todennäköisesti tottunut odottamaan – otsikko, sisältö ja metatiedot. Myönnettäköön, että nämä ominaisuudet ovat vain merkkijonoja, mutta ne voivat olla yksityiskohtaisempia tietorakenteita todellisessa tilanteessa.

Katsotaanpa nyt postausta :

<?php

class Post extends Content  {

   private $author;

   public function __construct() {
     parent::__construct();
     $this->author = "Tom McFarlin";
   }

   public function getAuthor()
   {
     return $this->author;
   }
 }

Mitä sitten tapahtuu, jos kutsut menetelmää Post – luokassa, kuten getTitle, jota ei ole olemassa, mutta se on olemassa Content – luokassa? Sitten perinnöllisyyden vuoksi se etsii menetelmää Viestistä, ei löydä sitä, ja alkaa sitten etsiä sitä Sisältöstä.

Jos se löytyy, se ajaa sen.

Vastaavasti voimme tehdä jotain tämän kaltaista sivuluokka- ja sisältötiedoilla. Ensin instantoimme perusluokan ja asetamme sitten sivulle ominaiset ominaisuudet. Tässä tapauksessa se tulee olemaan luokka.

<?php

class Page extends Content  {

   private $category;

   public function __construct() {
     parent::__construct();
     $this->category = "Articles";
   }

   public function getCategory()
   {
     return $this->category;
   }
 }

Nyt kun suoritamme koodin, voimme aloittaa sisällöstä:

<?php

$content = new Content();
echo $content->getTitle();

Huomaa, että tämä näyttää siltä, ​​mitä odotimme, koska meillä on otsikko ja meillä on sisältöä. Katsotaanpa myös viestiä :

<?php

// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();

Tämä toimii, koska meillä on kirjoittaja, mutta meillä on myös otsikko, koska se sijaitsee Sisältössä. Mutta jos yritämme kutsua getAuthoria Post -instanssissa?

<?php

// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();

Saamme virheilmoituksen, koska menetelmä ei ole kyseisessä luokassa.

Mitä meidän pitää tehdä? Koska meillä ei ole vahvoja tyyppejä PHP:ssä, emme voi lähettää sitä eri tyyppiin.

Tätä varten on olemassa suunnittelumalleja, joista aion keskustella tulevissa postauksissa, mutta PHP ei salli tätä yhtä helposti kuin jotkut muut kielet (kuten C# tai Java).

Kysymyksiä polymorfismista

Toivottavasti yllä oleva koodi antaa sinulle käsityksen siitä, kuinka tietyllä konkreettisella tyypillä, kuten viestillä  tai sivulla, voi implisiittisesti olla ajon aikana käytettävän perusluokkansa Content ominaisuudet ja menetelmät  .

Mutta se herättää myös muutamia kysymyksiä, eikö niin? Esimerkiksi:

• Miksi polymorfismi on hyödyllistä? Viime kädessä kyse on joustavuudesta. Toisin sanoen voit kirjoittaa yleisen sisältötyypin, mutta luoda sitten viestin tai sivun, kuten edellä on nähty. Tämä antaa meille sitten kaikki Sisältö – luokan edut ja  antaa meille myös esimerkiksi Post – luokan erityispiirteen.
• Tämä näyttää olevan enemmän hämmentävä kuin joustava. Se on tavallaan hämmentävää, koska koodi vaatii hieman jäljitystä. Toisin sanoen saatat aloittaa Post – luokasta ja joutua katsomaan, mitä Sisältö – luokka tarjoaa. Toisaalta sen avulla on todella helppoa ottaa käyttöön uusi Sisältö -alaluokka ja sitten käyttää sitä silloin, kun se sopii parhaiten suoritusaikana.

Mitä tulee yliluokkiin ja alaluokkiin, tässä tulee esiin vankka IDE.

On aina mukavaa, jos sinulla on editori, josta pidät, mutta sellaisen editori, joka voi intuitiivisesti määrittää, mikä on pääluokka, mikä on perusluokka jne., voi auttaa jäljittämään, jäljittämään, jäljittämään, seuraamaan ja kirjoittamaan uusia. koodi.

Mutta se on sisältöä toiseen postaukseen, joka tulee sen jälkeen, kun puhumme suunnittelumalleista.