Kiedy zaczynałem tę serię, mówiłem o czterech filarach programowania obiektowego. Każdy z tych tematów jest wymieniony i połączony poniżej.
W tym momencie normalnie chciałbym przejść do następnego tematu. Jednak zanim to zrobię, chciałbym poświęcić jeszcze jeden post na badanie pojęcia polimorfizmu.
W swojej dotychczasowej karierze widziałem kilka tematów, które przysparzają osobom zajmującym się programowaniem obiektowym więcej zamieszania i problemów niż polimorfizm. Dlatego chciałbym omówić to nieco bardziej szczegółowo w kontekście programowania obiektowego i poza konkretnym frameworkiem lub aplikacją (jak WordPress).
W tym poście zrobię szybki przegląd tego, co omówiliśmy do tej pory, a następnie wskoczę z powrotem do polimorfizmu.
Polimorfizm dogłębny
Po pierwsze, jak wspomniano, chcę szybko przejrzeć to, co zostało omówione do tej pory, zwłaszcza jeśli przeoczyłeś którykolwiek z poprzednich postów.
Nie martw się: nic poniżej nie wnika w kod. Zamiast tego po prostu definiuje terminy, których użyliśmy, więc masz pewne pojęcie o tym, do czego mam na myśli, gdy zobaczysz słowo pojawiające się w tej serii.
Abstrakcja
Abstrahujemy ideę czegoś w klasę. Zamiast tego będziemy abstrahować pomysły do ich klas. I tutaj jest kluczowa idea: klasa powinna reprezentować rzeczownik.
Kapsułkowanie
Enkapsulacja to tak naprawdę tylko „duże" słowo, które odnosi się do idei zarządzania swoimi obowiązkami (lub śledzenia swoich danych).
Dziedzictwo
Dziedziczenie odnosi się do idei, że jedna klasa, chociaż ma własną implementację, dosłownie dziedziczy właściwości, funkcje i ogólną implementację z klasy nadrzędnej.
Wielopostaciowość
Polimorfizm pozwala nam odnosić się do klasy jednego typu, kiedy może być zadeklarowana jako inny typ.
Mając to na uwadze, myślę, że tutaj sprawy mogą się nieco bardziej skomplikować. W poprzednich postach podałem szereg różnych przykładów kodu (i zachęcam do spojrzenia na nie).
Ale w dzisiejszym poście spróbuję zbadać tę ideę nieco dalej, zarówno w wyjaśnieniu, jak i w kodzie.
Odnoszące się do dziedziczenia
Jeśli w tym momencie nie jest to oczywiste, polimorfizm jest silnie związany z dziedziczeniem. Pomyśl o tym w ten sposób: Jeśli jedna klasa dziedziczy właściwości i metody z innej klasy, to może „zastąpić” klasy nadrzędnej.
Oznacza to, że jeśli masz coś takiego jak klasa Content, a następnie masz dwie podklasy, jedną będącą Postem, a drugą będącą Page, możesz utworzyć instancję klasy, używając odwołania do Content type.t
Ale w czasie wykonywania będzie to faktycznie instancja typu Post. Ma sens? Oto przykładowy kod.
Najpierw zaczniemy od zdefiniowania klasy Content :
<?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;
}
}
Ma ogólne właściwości, których prawdopodobnie oczekujesz – tytuł, treść i metadane. To prawda, że te właściwości są tylko ciągami, ale mogą być bardziej rozbudowanymi strukturami danych w sytuacji rzeczywistej.
Teraz spójrzmy na post :
<?php
class Post extends Content {
private $author;
public function __construct() {
parent::__construct();
$this->author = "Tom McFarlin";
}
public function getAuthor()
{
return $this->author;
}
}
Co się stanie, jeśli wywołasz metodę w klasie Post, taką jak getTitle, która nie istnieje, ale istnieje w klasie Content? Następnie ze względu na dziedziczenie będzie szukać metody w Post, a nie znaleźć jej, a następnie zacznie szukać jej w Content.
Jeśli zostanie znaleziony, uruchomi go.
Podobnie możemy zrobić coś takiego z klasą Page i danymi zawartości. Najpierw tworzymy instancję klasy bazowej, a następnie ustawiamy właściwości specyficzne dla Page. W tym przypadku będzie to kategoria.
<?php
class Page extends Content {
private $category;
public function __construct() {
parent::__construct();
$this->category = "Articles";
}
public function getCategory()
{
return $this->category;
}
}
Teraz, gdy uruchomimy kod, możemy zacząć od zawartości:
<?php
$content = new Content();
echo $content->getTitle();Zwróć uwagę, że wygląda to tak, jak byśmy się spodziewali, ponieważ mamy tytuł i zawartość. Spójrzmy też na Post :
<?php
// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();To działa, ponieważ mamy autora, ale mamy też tytuł, ponieważ znajduje się on w treści. Ale jeśli spróbujemy wywołać getAuthor na instancji Post?
<?php
// These will work because they reside in the Content base class.
$post = new Post();
echo $post->getAuthor();
echo $post->getTitle();Otrzymamy błąd, ponieważ metoda nie znajduje się w tej klasie.
Więc co mamy zrobić? Ponieważ nie mamy silnych typów w PHP, nie możemy rzutować go na inny typ.
Istnieją na to wzorce projektowe, które omówię w przyszłych wpisach, ale PHP nie pozwala na to tak łatwo, jak niektóre inne języki (takie jak C# lub Java).
Pytania dotyczące polimorfizmu
Mamy nadzieję, że powyższy kod daje wyobrażenie o tym, w jaki sposób konkretny typ, taki jak Post lub Page, może niejawnie mieć właściwości i metody swojej klasy bazowej Content, używanej w czasie wykonywania.
Ale rodzi też kilka pytań, prawda? Na przykład:
- Dlaczego polimorfizm jest przydatny? Ostatecznie jest to kwestia elastyczności. Oznacza to, że możesz napisać ogólny typ treści, a następnie utworzyć post lub stronę, jak widzieliśmy powyżej. Daje nam to wszystkie zalety klasy Content, jednocześnie dając nam na przykład specyfikę klasy Post.
- Wydaje się to bardziej mylące niż elastyczne. W pewnym sensie jest to mylące, ponieważ kod wymaga trochę śledzenia. Oznacza to, że możesz zacząć od klasy Post i musisz sprawdzić, co oferuje klasa Content . Z drugiej strony ułatwia to również wprowadzenie nowej podklasy Content, a następnie używanie jej, gdy jest najbardziej odpowiednia w czasie wykonywania.
Jeśli chodzi o odwoływanie się do nadklas i podklas, w tym miejscu w grę wchodzi solidne IDE.
Oczywiście fajnie jest mieć edytor, który ci się podoba, ale posiadanie takiego, który może intuicyjnie określić, co jest klasą nadrzędną, co jest klasą bazową itp., może znacznie pomóc w śledzeniu, debugowaniu, śledzeniu i pisaniu nowych kod.
Ale to już treść na kolejny post, który pojawi się po tym, jak porozmawiamy o wzorcach projektowych.