Kui ma seda sarja alustasin, rääkisin objektorienteeritud programmeerimise neljast sambast. Kõik need teemad on loetletud ja lingitud allpool.
Siinkohal tahaksin tavaliselt alustada järgmise teemaga liikumist. Enne seda tahaksin aga veeta veel ühe postituse polümorfismi kontseptsiooni uurimiseks.
Oma senise karjääri jooksul olen näinud väheseid teemasid, mis tekitavad objektorienteeritud programmeerimisega tegelejatele rohkem segadust ja probleeme kui polümorfism. Seega tahaksin seda objektorienteeritud programmeerimise kontekstis ja väljaspool konkreetset raamistikku või rakendust (nt WordPress) veidi põhjalikumalt arutada.
Selles postituses annan kiire ülevaate sellest, mida oleme seni arutanud, ja seejärel hüppan tagasi polümorfismi juurde.
Põhjalik polümorfism
Esiteks, nagu mainitud, tahan kiiresti üle vaadata, mida seni on arutatud, eriti kui olete mõne eelneva postituse varju jätnud.
Ärge muretsege: miski allpool ei muutu koodiks. Selle asemel määratleb see lihtsalt terminid, mida oleme kasutanud, nii et teil oleks aimu, millele ma viitan, kui näete selle seeria jooksul seda sõna.
Abstraktsioon
Abstraheerime idee millestki klassi. Selle asemel abstraheerime ideid nende klassidesse. Ja siin on põhiidee: klass peaks esindama nimisõna.
Kapseldamine
Kapseldamine on tegelikult lihtsalt "suur" sõna, mis viitab ideele oma kohustuste haldamisest (või andmete jälgimisest).
Pärand
Pärimine viitab ideele, et ühel klassil, kuigi sellel on oma teostus, pärib see sõna otseses mõttes ülemklassi omadused, funktsioonid ja üldise teostuse.
Polümorfism
Polümorfism võimaldab meil viidata ühe tüübi klassile, kui seda võidakse deklareerida teise tüübina.
Sellega seoses arvan, et siin võivad asjad veidi keerulisemaks minna. Eelmistes postitustes olen pakkunud mitmeid erinevaid koodinäiteid (ja soovitan tungivalt neile tagasi vaadata).
Kuid tänases postituses proovin seda ideed veidi lähemalt uurida nii selgituses kui ka koodis.
Seoses pärandiga
Kui see pole sel hetkel ilmne, on polümorfism tugevalt seotud pärimisega. Mõelge sellele järgmiselt: kui üks klass pärib atribuudid ja meetodid teiselt klassilt, võib see ülemklassi "paigal seista".
See tähendab, et kui teil on midagi nagu sisuklass ja teil on kaks alamklassi, millest üks on postitus ja teine on leht, saate klassi eksemplari luua, kasutades sisu viitetüüpi.t
Kuid käitusajal on see tegelikult Postitus tüüpi eksemplar. On loogiline? Siin on näitena mõni kood.
Esiteks alustame sisuklassi määratlemisega :
<?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;
}
}
Sellel on üldised omadused, mida olete tõenäoliselt oodanud – pealkiri, sisu ja metaandmed. Tõsi, need atribuudid on vaid stringid, kuid reaalses olukorras võivad need olla keerukamad andmestruktuurid.
Vaatame nüüd postitust :
<?php
class Post extends Content {
private $author;
public function __construct() {
parent::__construct();
$this->author = "Tom McFarlin";
}
public function getAuthor()
{
return $this->author;
}
}
Mis juhtub siis, kui kutsute välja meetodi Post – klassis, nagu getTitle, mida pole olemas, kuid klassis sisu on see olemas? Seejärel otsib see pärimise tõttu meetodit jaotisest Postitus, mitte ei leia seda, ja hakkab seejärel otsima seda jaotisest Sisu.
Kui see leitakse, käivitab see selle.
Samamoodi saame midagi sellist teha lehe klassi ja sisu andmetega. Esiteks loome baasklassi ja seejärel määrame lehele spetsiifilised atribuudid. Sel juhul on see kategooria.
<?php
class Page extends Content {
private $category;
public function __construct() {
parent::__construct();
$this->category = "Articles";
}
public function getCategory()
{
return $this->category;
}
}
Nüüd, kui me koodi käivitame, saame alustada sisuga:
<?php
$content = new Content();
echo $content->getTitle();Pange tähele, et see tundub ootuspärane, kuna meil on pealkiri ja meil on sisu. Vaatame ka postitust :
<?php
// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();See toimib, kuna meil on autor, kuid meil on ka pealkiri, kuna see asub sisus. Aga kui me proovime Post eksemplaril kutsuda getAuthor?
<?php
// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();Saame veateate, kuna meetod ei asu selles klassis.
Mida me siis tegema peame? Kuna meil pole PHP-s tugevaid tüüpe, ei saa me seda teisele tüübile üle kanda.
Selle jaoks on olemas kujundusmustrid, millest räägin järgmistes postitustes, kuid PHP ei võimalda seda nii lihtsalt kui mõned teised keeled (nt C# või Java).
Küsimused polümorfismi kohta
Loodetavasti annab ülaltoodud kood teile aimu, kuidas konkreetsel tüübil, näiteks postitusel või leheküljel, võivad kaudselt olla käitusajal kasutatavad põhiklassi Sisu omadused ja meetodid.
Kuid see tekitab ka paar küsimust, kas pole? Näiteks:
- Miks on polümorfism kasulik? Lõppkokkuvõttes on see paindlikkuse küsimus. See tähendab, et saate kirjutada üldise sisutüübi, kuid seejärel luua postituse või lehe, nagu eespool nägime. See annab meile kõik sisuklassi eelised, andes meile ka näiteks klassi Post spetsiifilisuse.
- See näib olevat rohkem segadust tekitav kui paindlik. Mõnes mõttes on see segane, sest kood nõuab natuke jälgimist. See tähendab, et võite alustada klassist Postitus ja vaadata, mida sisuklass pakub. Teisest küljest muudab see väga lihtsaks uue sisu alamklassi tutvustamise ja selle kasutamise siis, kui see käitusajal kõige paremini sobib.
Mis puutub ülem- ja alamklassidesse, siis siin tuleb mängu kindla IDE olemasolu.
Alati on tore, kui teil on redaktor, mis teile meeldib, kuid kui teil on redaktor, mis suudab intuitiivselt kindlaks teha, mis on põhiklass, mis on põhiklass jne, võib see aidata jälgida, siluda, jälgida ja uusi kirjutada. kood.
Kuid see on teise postituse sisu, mis tuleb pärast seda, kui räägime disainimustritest.