Część 4 – WordPress i programowanie obiektowe: przykład WordPressa – projektowanie

W tym momencie mamy jasno określone wymagania, tak jak zostały one opisane w części 3 tej serii (sprawdź je tutaj, jeśli je przegapiłeś).

Nadszedł czas, aby zacząć myśleć o projekcie naszej nowej i ulepszonej wtyczki!

Przypominamy, że ten krok może zająć Ci dużo czasu, gdy będziesz wypróbowywał go we własnych projektach. Prawdopodobnie za pierwszym razem też nie wszystko będzie dobrze. Szanse są takie, że wymyślisz projekt, zaczniesz go wdrażać, a potem zdasz sobie sprawę, że musisz wrócić i przemyśleć swoje podejście.

Jest to całkowicie warte wysiłku, więc poświęć tyle czasu, ile potrzeba, aby wszystko było w porządku. Dobrze skonstruowany projekt ułatwi jego utrzymanie i rozszerzenie, a nawet ponowne wykorzystanie jego kodu w innych projektach, więc na dłuższą metę jest to dobre wykorzystanie czasu.

Zaraz potem skupimy się na kilku kluczowych częściach wtyczki i omówimy, jak wymyśliliśmy nasz projekt.

Przecinanie strony ustawień

Przyjrzyjmy się bliżej stronie administratora wtyczki.

Zauważysz, że na dole strony znajduje się tytuł („Ustawienia limitu prób logowania”), kilka sekcji zawierających niektóre pola oraz przycisk „Zmień opcje”.

Każda sekcja składa się z tytułu, np. „Statystyki” i kilku pól.

Każde pole ma tytuł po lewej stronie, a reszta jego zawartości po prawej stronie. Istnieją pola tekstowe, przyciski radiowe i pola wyboru, a niektóre z nich, takie jak „Całkowite blokady”, wyświetlają tylko informacje i nie mogą być bezpośrednio modyfikowane przez administratora.

Niektóre pola zawierają również opis, na przykład pole „Połączenie z witryną”, ale nie wszystkie.

Mając powyższe na uwadze, musimy podzielić to na części koncepcyjne, które później staną się klasami.

API ustawień WordPressa pozwala nam rejestrować strony ustawień, sekcje na tych stronach i pola w sekcjach:

Strony → Sekcje → Pola

Pomyśleliśmy, dlaczego nie dodać jeszcze jednej „warstwy”, Elementów, aby ułatwić rozbudowę naszej wtyczki w przyszłości.

Strony → Sekcje → Pola → Elementy

Tak więc strony i sekcje są tym, co już wyjaśniliśmy powyżej, a pola będą zawierać elementy dowolnego typu zawartości po prawej stronie.

Biorąc pod uwagę wszystkie te różne rodzaje elementów, wybraliśmy klasę Element i kilka klas, rozszerzając ją o pola wyboru, przyciski radiowe, liczby itp., które będą renderować różne wyniki.

W przyszłości może być konieczne dodanie większej liczby stron i sekcji. Jest więc prawdopodobne, że musielibyśmy rozszerzyć te klasy strony administratora i sekcji.

To samo dotyczy pól. Klasy dla „Całkowitych blokad”, „Aktywnych blokad” itp. Rozszerzą tę samą (nadrzędną) klasę.

Oto uproszczona grafika, która pokazuje te relacje:

Oczywiście nie wszystkie „komponenty” są uwzględnione na schemacie.

Taka struktura ułatwia rozszerzenie wtyczki; jesteśmy w stanie łatwo dodać pole, element lub sekcję, jeśli zajdzie taka potrzeba. Będziemy mogli łatwo dodawać więcej komponentów — pól, elementów lub sekcji — tworząc nowe klasy podrzędne, bez konieczności modyfikowania już istniejących.

Myślenie i abstrahowanie

Teraz jest świetny czas, aby zacząć myśleć o tym, co robią poszczególne komponenty naszej wtyczki. W fazie projektowania nie musimy zagłębiać się w szczegóły dotyczące tego, jak coś działa.

Na przykład weź pod uwagę wszystkie elementy, tabele, statystyki i prawie wszystko, co będzie wyświetlane użytkownikowi. Mogą być oddzielnymi komponentami, które nie mają ze sobą nic wspólnego, ale ostatecznie wszystkie wygenerują część danych wyjściowych. Dlatego niektóre funkcje będą wspólne dla komponentów, które w przeciwnym razie są całkowicie niepowiązane. Oczywiście dotyczy to również pozostałych naszych komponentów.

W powyższej wizualizacji widzimy, jak interfejs interfejsu użytkownika jest implementowany przez wiele klas.

Zwróć uwagę, że interfejs UI jest implementowany przez klasy Statistics, Lockout Logs, Table i Element, które są określane jako klasy nadrzędne . Nie ma potrzeby, aby klasy Radio/Number/Checkbox Element bezpośrednio implementowały interfejs, ponieważ dziedziczą one wszystkie interfejsy ze swojej klasy nadrzędnej. Jednak klasa potomna może przesłonić metodę swojej klasy nadrzędnej.

Ponieważ wiemy, że nasza wtyczka zajmie się ustawieniami, możemy śmiało założyć, że odczytamy i zapiszemy ich wartości. Oznacza to możliwość pobierania , ustawiania i usuwania opcji.

Wszystkie te działania zostaną połączone w jedną klasę. Prawdopodobnie będziemy przechowywać nasze opcje w bazie danych WordPressa lub coś w tym stylu. Na razie nie musimy dbać o to, jak i gdzie będziemy przechowywać nasze dane.

Możemy zachować abstrakcję opcji pobierania/ustawiania/usuwania w naszych umysłach, upraszczając rzeczy koncepcyjnie i dalej projektując naszą wtyczkę.

Główny plik wtyczki

W tym miejscu podamy informacje o wtyczce do WordPressa poprzez komentarz w nagłówku i przeprowadzimy inicjalizację. Zorganizujemy nasz kod, pakując wszystko w małą klasę.

W zależności od tego, jak klasy naszej wtyczki będą ze sobą współpracować, większość z nich będzie musiała utworzyć klasa główna. O ile nam wiadomo, będzie to obejmować zajęcia związane z opcjami, stronami administracyjnymi, ponawianymi próbami i blokadami.

Potencjalne klasy

Poświęciliśmy trochę czasu, aby spróbować ustalić, jakich zajęć będziemy potrzebować, i otrzymaliśmy listę w następujący sposób:

• Ponowne próby
• Blokady
• Ciasteczka
• Komunikaty o błędach
• Powiadomienia e-mailowe
• Powiadomienia administratora
• guziki
• Dzienniki blokad
• Aktywne/całkowite blokady
• adres IP

Pamiętaj, że nie ma jednego „poprawnego” sposobu na uporządkowanie wtyczki. Podobnie jak w przypadku większości rzeczy związanych z tworzeniem oprogramowania, istnieje wiele równie ważnych sposobów rozwiązania problemu.

Na przykład w sekcji „Ogólne” relacje między naszymi klasami wyglądałyby tak:

Sekcja „Statystyki” będzie podobna do tej:

Wreszcie „Dzienniki blokad” będą bardzo podobne do „Statystyk”:

Wniosek

Do tej pory zdefiniowaliśmy nasze wymagania i pomyśleliśmy o projekcie naszej nowej i ulepszonej wtyczki. Wyjaśniliśmy, w jaki sposób wymyśliliśmy naszą strukturę, a także przedstawiliśmy kilka prostych diagramów pokazujących, w jaki sposób nasze klasy będą ze sobą powiązane.

Kliknij tutaj, aby przeczytać część 5 w naszej serii programowania zorientowanego na obiekt

Zobacz też

• WordPress i programowanie obiektowe – przegląd
• Część 2 – WordPress i programowanie obiektowe: przykład ze świata rzeczywistego
• Część 3 – WordPress i programowanie obiektowe: Α Przykład WordPress – definiowanie zakresu