W poprzednim poście z tej serii przeszedłem przez:
- podstawy klas abstrakcyjnych,
- jak je wdrożyć,
- i podał działające przykłady kodu.
I chociaż uważam, że zrozumienie klas abstrakcyjnych jest kluczem do stworzenia silnych podstaw programowania obiektowego, często widzę, że może to być mylące, jeśli chodzi o porównywanie ich z interfejsami i wiedza, kiedy ich używać.
Klasy abstrakcyjne i interfejsy
W tym poście udostępnię:
- szybkie przypomnienie o tym, czym są interfejsy,
- czym są klasy abstrakcyjne,
- a następnie, jak wiedzieć, kiedy użyć jednego z drugim.
Nie powinien to być artykuł intensywnie kodujący, ale powinien pomóc wiedzieć, kiedy pisać kod określonego typu, aby pomóc w lepszej organizacji projektów.
1 Interfejsy
Przypomnijmy, że jeśli chodzi o interfejsy, używamy również terminu „programowanie do interfejsu" z myślą o tym, że interfejs definiuje metody, które klasa musi zaimplementować, aby wypełnić „kontrakt” z tym interfejsem.
Kod użyty do zademonstrowania podstawowego interfejsu to:
<?php
interface iCache
{
public function set($key, $value);
public function get($key);
public function has($key);
}
Pamiętaj jednak, że celem interfejsu nie jest definiowanie po napisaniu kodu. Zamiast tego jest to narzędzie używane do projektowania, jakie klasy powinny zaimplementować, jeśli będą przestrzegać określonego paradygmatu lub jeśli wymagają określonego zestawu funkcji.
Oznacza to, że jeśli zamierzasz projektować zestaw klas, które działają z buforowaniem, nie piszesz najpierw klas. Najpierw piszesz interfejs, a następnie klasy implementują ten interfejs.
Chodzi o to, że każda klasa implementująca interfejs będzie mieć te funkcje.
2 Klasy abstrakcyjne
Z drugiej strony klasy abstrakcyjne pozwalają nam robić dwie rzeczy:
- implementować funkcjonalność, z której mogą korzystać podklasy,
- implementuj sygnatury metod, które muszą implementować podklasy.
Na początku może wydawać się to trochę niespójne, ale rozważ to:
Kiedy masz klasę pewnego typu, która będzie miała spójną funkcjonalność bez względu na podklasę, funkcjonalność przechodzi do klasy abstrakcyjnej. Gdy inne metody wymagają implementacji metody, wystarczy podać sygnaturę metody i oznaczyć ją jako abstract.
Oto przykład z poprzedniego postu:
To sprawia, że wszyscy jesteśmy zajęci poprzednimi przykładami i poprzednimi rzeczami, na których musimy się skupić, jeśli chodzi o interfejsy i klasy abstrakcyjne, ale dla niektórych nadal nie zapewnia to zbytniej jasności.
Konkretnie, to nadal nie odpowiada na pytanie: Jak decydujemy, kiedy użyć klasy abstrakcyjnej, a kiedy użyć interfejsu?
Na pierwszy rzut oka może to zabrzmieć nieco mylące, ale jest kilka rzeczy, których możesz użyć, aby podjąć decyzję.
Kiedy używamy każdego?
Pamiętaj, że jeśli chodzi o programowanie obiektowe, możemy je podzielić na trzy różne sposoby:
- Zajęcia reprezentują rzecz. Możesz uznać to za rzeczownik.
- Atrybuty lub właściwości są jak przymiotniki. Opisują przedmiot lub coś, co przedmiot może posiadać.
- Metody lub funkcje są jak czasowniki. Opisują, co mogą zrobić ich sprzeciw.
Teraz, jeśli chodzi o interfejs, zastanów się, co ten interfejs robi: opisuje, bez implementacji, co może zrobić obiekt. A jeśli chodzi o klasę abstrakcyjną, opisuje, czym jest obiekt w czasie wykonywania.
Innymi słowy, dobrą zasadą jest to, że jeśli potrzebujesz zapewnić zestaw zachowań dla obiektu, interfejs jest dobrym rozwiązaniem. Jeśli chcesz opisać, czym jest obiekt, użyj klasy abstrakcyjnej.
W przypadku klas abstrakcyjnych pójdę o krok dalej i powiem, że pomaga opisać podstawowy poziom danych, który opisuje obiekt lub to, co może przechowywać oprócz podstawowego poziomu funkcjonalności.
Masz przykład?
Podobnie jak w przypadku większości treści w każdym z tych postów, staram się podać przykłady, nawet jeśli nie jest to specjalnie zrobione w kodzie. Być może pomoże to wyjaśnić to jeszcze bardziej:
- Interfejsy nie mają implementacji. Gwarantują tylko to, co zrobi klasa.
- Klasy abstrakcyjne powinny mieć podstawowy poziom implementacji. Powinno to reprezentować, co klasa może posiadać i zrobić, ale nie jest kompletna. Wymagają nieco więcej implementacji z podklasy.
Kiedy pracujesz z kodem obiektowym, mam nadzieję, że pomoże to w dostarczeniu wskazówek, kiedy używać czego. Jeśli nie, nie wahaj się zostawić komentarza (coś, na co członkowie mają pozwolenie :).
Co więcej, zobaczymy to w praktyce, gdy przejdziemy do pisania kodu obiektowego (zwłaszcza dla WordPressa, ale nie zawsze).