W poprzednim poście zacząłem przechodzić przez proces przekształcania pomysłu na wtyczkę, która szybko ją prototypuje, w coś, co działa w WordPressie. I chociaż to działa, niekoniecznie jest zgodne z zasadami zorientowanymi obiektowo, ani nie jest to miejsce, w którym możemy łatwo dodawać funkcje.
Nie, to nie jest argument, dlaczego orientacja obiektowa jest lepsza. Tak się składa, że jest to mój ulubiony sposób pisania kodu, więc podchodzę do tego w ten sposób.
Wiem, że przykładowy kod, który podaję, jest prosty i wiem, że można sprawić, że coś takiego można pozostawić bez zmian. Ale chodzi o to, aby pokazać, jak wziąć koncepcję, stworzyć jej prototyp, a następnie przenieść ją do czegoś, co jest zgodne z zasadami zorientowanymi obiektowo.
Z mojego doświadczenia wynika, że jest to o wiele trudniejsze od samego początku na złożonym przykładzie. jeśli stracisz czytelników od samego początku, to jaka jest nadzieja, że zrozumieją, co nadchodzi?
Mając to na uwadze, przyjrzymy się kodowi z poprzedniego postu i przeprowadzimy na nim trochę analizy koncepcji, aby zobaczyć, co może dobrze działać w klasie i jak możemy zacząć organizować ją za pomocą klas, przestrzenie nazw i tak dalej.
Analiza koncepcji
Kiedykolwiek przychodzi do programowania, tak łatwo jest chcieć natychmiast przejść do pisania kodu, a następnie zmusić go do złożenia, aż zrobi coś, czego chcemy.
A kiedy to zadziała, wydaje się, że skończyliśmy i możemy przejść do następnego zadania. Ale w przypadku większych projektów nie zawsze tak jest. W rzeczywistości często lepiej jest przeprowadzić trochę analizy koncepcji analizy obiektowej w swoim projekcie przed przejściem do przodu.
Proste przejście do kodowania nie zawsze jest najlepszym podejściem.
Przypadek do analizy
Przykład: w momencie pisania tego tekstu, jeden z moich kolegów z zespołu i ja dyskutujemy, czy powinniśmy rozszerzyć klasę, czy napisać nową klasę do obsługi informacji o geolokalizacji dla danych pobranych z Google Maps API.
Czy mogę to zrobić i napisać coś, co działa? Pewny. Ale czy dobrze zintegruje się z aplikacją? Nie bez analizy koncepcji, planowania i koordynacji z resztą systemu.
I o to właśnie chodzi w analizie.
Analizowanie naszej pracy
Więc co to oznacza dla wtyczki, którą oglądaliśmy wczoraj? W tej chwili mamy:
- funkcja odpowiedzialna za tworzenie metaboxa i wyświetlanie w nim zawartości,
- funkcja odpytywania bazy danych i pobierania ostatnich najnowszych postów,
- funkcja wyświetlania wyników w metabox
- funkcja do wyświetlania wiadomości, gdy w meta polu nie ma wyników
Co więcej, wiele z tych funkcji jest powiązanych z hookami, które są częścią API WordPressa. Mianowicie, funkcja tworzenia metaboxa jest podłączona do WordPressa, a towarzysząca mu funkcja renderowania wyświetlacza jest częścią tego samego komponentu.
Następnie mamy funkcjonalność do odpytywania bazy danych oraz funkcje bezpośrednio związane z widokami.
Jak więc mogłoby to wyglądać, gdybyśmy podzielili to na różne klasy i pliki, które pomogłyby stworzyć to w sposób bardziej zorientowany obiektowo?
Brak jednego rozwiązania
Nie ma jednego rozwiązania, a niektóre rozwiązania są znacznie bardziej zaawansowane niż inne. Ale ponieważ staram się zachować równowagę, zamierzam podejść do tego w prostszy sposób niż za dużo pracy z abstrakcją, dziedziczeniem, interfejsami i tym wszystkim.
Koncentrowanie się na tym, co mamy
Na razie skupmy się na poszczególnych zajęciach i obowiązkach, jakie mogą pełnić. Na przykład:
- Myślę, że będziemy potrzebować klasy, która reprezentuje pole meta. Powinno to być odpowiedzialne za stworzenie pola meta.
- Będziemy też potrzebować klasy odpowiedzialnej za wyświetlanie zawartości pola meta. Możesz pomyśleć, że dołączenie funkcji do klasy dla pola meta działa dobrze. To robi; jeśli jednak chcesz myśleć o każdej klasie jako o pojedynczej odpowiedzialności, możemy utworzyć klasę specjalnie dla wyświetlacza i specjalnie dla pola meta, a następnie wstrzyknąć ekran do pola meta podczas tworzenia instancji. Porozmawiamy o tym później.
W tym momencie nasz diagram może wyglądać mniej więcej tak:
Rozkładanie meta boxu.
Następnie musimy rozważyć inną funkcjonalność. Mianowicie funkcjonalność wyświetlania wyników w polu meta i funkcjonalność wyświetlania wyników, gdy ich nie ma.
Aby wyświetlić cokolwiek w polu meta, musimy mieć sposób na zapytanie bazy danych w celu pobrania wyników. Stamtąd musimy być w stanie określić, czy istnieją wyniki, a jeśli nie, a następnie wprowadzić te wyniki do widoku.
Biorąc pod uwagę te informacje, wygląda na to, że potrzebujemy klasy do odpytywania bazy danych, a następnie potrzebujemy klasy, aby rozszerzyć komunikat na wyświetlanie pola meta.
Być może jeden ze sposobów organizacji zajęć wyglądałby tak:
Przeszukiwanie bazy danych i przygotowywanie wiadomości.
Ostateczna wersja diagramu może być trochę ciasna, ale ostatecznie patrzymy na coś takiego:
Ostateczna organizacja naszych zajęć.
Do celów wyjaśnienia:
- Program pobierający posty pyta bazę danych o ostatnie trzy najnowsze posty.
- Komunikator pocztowy określi, którą wiadomość wstawić na wyświetlacz.
- Wyświetlacz wyświetli ustawiony komunikat.
- Metabox wyrenderuje swoje wyświetlanie w przeglądarce internetowej.
Więc zasadniczo wzięliśmy kilka funkcji, które były podłączone do WordPressa i podzieliliśmy je na komponenty, które mogą się ze sobą komunikować, z których każda jest stosunkowo łatwa w obsłudze i nie wykonuje więcej niż jednej pracy.
Konwersja na kod
Teraz, gdy mamy pomysł, jak przekonwertować poprzednią koncepcję na kod, przyjrzymy się, jak to zrobić w kilku następnych artykułach.
Zauważ, że sposób, w jaki zdecydujesz się zaimplementować swój kod lub zaprojektować swoje klasy, może być nieco inny niż to, co mam powyżej i możesz mieć sugestie, jak lepiej zorganizować to, co powyżej. Jeśli tak jest, zostaw komentarz.
W następnym poście przyjrzymy się przekształceniu tego w funkcjonalny kod, a następnie przyjrzymy się zorganizowaniu tego we właściwe przestrzenie nazw i właściwą organizację plików.
Posty z serii
- Szybkie prototypowanie z WordPress: od koncepcji do wtyczki
- Szybkie prototypowanie z WordPress: analiza koncepcji
- Szybkie prototypowanie: Prototypowanie do kodu, część 1
- Szybkie prototypowanie: Prototypowanie do kodu, część 2
- Szybkie prototypowanie: Przedstawiamy automatyczne ładowanie