W tym miejscu powiedziałbym, że fundamenty zrozumienia programowania obiektowego zostały już położone.
W szczególności omówiłem:
I tak, toczy się debata na temat tego, co stanowi podstawy (to znaczy, niektórzy nie wrzucają polimorfizmu do mieszanki, chociaż ja to robię). Ale powyższe cztery powinny zapewnić solidną podstawę do dalszego budowania umiejętności programowania obiektowego.
Jest ich więcej, ale nie sądzę, że są tak głębokie, szczegółowe lub trudne do zrozumienia, jak niektóre z wyżej wymienionych koncepcji. Z drugiej strony różne rzeczy przychodzą innym łatwiej.
W każdym razie kolejne dwa tematy, które należy zrozumieć, to:
- Interfejsy
- Abstrakcja
Opowiem o każdym z osobna, ale upewnij się, że najpierw przeczytałeś serię Podstawy, ponieważ powyższe dwa tematy pozwolą ci na nich polegać i czerpać z nich korzyści.
Niejasne, wiem, ale pozwól, że wyjaśnię, a potem odejdę.
Zrozumienie interfejsów
Zdecydowanie najczęstszą definicją interfejsu, którą prawdopodobnie usłyszysz, jest to, że jest to umowa. To nie jest złe, ale myślę, że pozostawia wiele do życzenia.
Na przykład, kiedy myślisz o umowach, prawdopodobnie myślisz o czymś, co jest bardzo zaangażowane, dużo żargonu, skomplikowany proces podpisywania czegoś, datowania, gotowości do pracy i robienia tego dalej.
Ale jeśli chodzi o interfejsy programistyczne, tak naprawdę nie jest. W rzeczywistości twierdzę, że definiowanie interfejsów może ułatwić programowanie i łagodzi wiele biurokracji, ponieważ sprawia, że rzeczy są bardzo czarne lub białe, jeśli chodzi o to, co należy zaimplementować.
Słowo o „interfejsach"
Nasza branża używa słowa „interfejs” do dwóch rzeczy:
- Projektanci i użytkownicy używają terminu interfejs, aby opisać to, co widzą i jak wchodzą w interakcję z aplikacją. Obejmuje to takie rzeczy, jak przyciski, listy rozwijane i inne elementy, których możemy „dotykać”.
- Programiści używają tego terminu w odniesieniu do funkcji, które podklasa musi zaimplementować, aby była zgodna z interfejsem. Nazywa się to „programowaniem do interfejsu”.
To ostatnie zostanie omówione w tym artykule. I nie, nie będziemy używać typowych przykładów, takich jak programowanie w interfejsie Animal lub cokolwiek innego. Zamiast tego przyjrzymy się temu na podstawie rzeczywistych próbek kodu.
Programowanie do interfejsu
Definiujemy „programowanie do interfejsu” jako sposób na napisanie kodu, który implementuje sygnatury funkcji zdefiniowanych w tym interfejsie.
Ale czym są sygnatury metod? Mówiąc najprościej, sygnatury metod obejmują:
- nazwa nazwy funkcji,
- potrzebne argumenty,
- modyfikator widoczności
W kontekście klasy zobaczysz to tak:
<?php
class Cache
{
public function set($key, $value)
{
// method implementation
}
}
Łatwe, prawda?
W powyższym kodzie widzimy, że funkcja set akceptuje klucz i wartość, która będzie używana, a funkcja jest dostępna dla każdego obiektu, który ma odniesienie do klasy.
Ale interfejsy również mogą to obejmować. Jest jednak zastrzeżenie: interfejsy nie mają implementacji metody.
Więc zamiast czegoś takiego:
<?php
class Cache
{
public function set($key, $value) {
set_transient($key, $value);
}
}
Zobaczysz to:
<?php
interface iCache
{
public function set($key, $value);
public function get($key);
public function has($key);
}
Ale w powyższym kodzie jest też kilka subtelności.
- Ten kod nie definiuje go jako klasy. Zamiast tego nazywa to interfejsem.
- Nazwa klasy jest poprzedzona „i”, aby wskazać, że jest to interfejs. Nie jest to wymagane; to konwencja.
- Metoda nie ma implementacji. Nie ma nic poza podpisem.
Kiedy tworzymy interfejs, mówimy, jak wspomniano powyżej, że każda klasa implementująca interfejs będzie definiować metody, które zawiera.
Więc gdybyśmy mieli powiązać wszystko, co widzieliśmy powyżej, ostateczna implementacja wyglądałaby tak (chociaż idealnie trzymalibyśmy to w osobnych plikach):
<?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);
}
}
I tak do siebie pasują interfejsy i klasy.
Otóż to?
Mówiąc prościej, tak. Ale z mojego doświadczenia odkryłem, że chodzi o coś więcej niż tylko definiowanie metod i ich wdrażanie.
Często łatwo jest zdefiniować klasy, następnie zdefiniować interfejs, a następnie zaimplementować interfejs. Ale to całkowicie zacofane. Zamiast tego musimy bardziej strategicznie myśleć o naszej pracy.
Zamiast cofać się do interfejsu, który całkowicie niweczy cel, musimy zacząć od szerokiego zakresu, aby nasze klasy mogły specjalizować się w tym, co robią przez cały czas, jednocześnie wdrażając funkcjonalność, która jest wspólna nie tylko dla tej klasy, ale także dla innych klas, które mogą potrzebować tej samej funkcjonalności.
Korzystając z powyższego przykładu, możemy mieć SimpleCache i TransientCache lub inny rodzaj pamięci podręcznej. Niezależnie od tego, jaki typ pamięci podręcznej zaimplementujemy, zaimplementują one interfejs, a funkcjonalność zostanie pozostawiona klasie implementującej interfejs.
Definiujemy więc, jak może wyglądać pamięć podręczna na wysokim poziomie, ale klasy implementujące dokładnie określą, jak będą funkcjonować.
Jeśli jesteś programistą WordPress i chcesz dowiedzieć się, jak tworzyć rzeczy na bazie aplikacji za pomocą praktycznych, obiektowych technik, dlaczego nie dołączyć do witryny?