Niedawno przeszedłem przez proces używania konstruktora klasy, aby uniemożliwić działanie wtyczki, jeśli nie zostanie załadowana oczekiwana zależność.
Chociaż nie uważam tej konkretnej strategii za problem w przypadku jednorazowej zależności lub w pewnych sytuacjach, istnieją sposoby, które mogą prowadzić do zapachów kodu.
Uniemożliwia nam również korzystanie z natywnej funkcji Core zwanej podakcjami WordPress:
https://twitter.com/JJJ/status/822265137935646720
Ale zanim przyjrzę się podakcji, chcę się upewnić, że mam jasność co do problemów, które przy użyciu podejścia warunkowego (w przeciwieństwie do podakcji) mogą rozmnażać się z zapachami kodu.
Podakcje WordPress
Zapachy kodu można wyjaśnić na wiele sposobów, ale mój ulubiony sposób pochodzi od Martina Fowlera :
…zapachy to pewne struktury w kodzie, które wskazują na naruszenie podstawowych zasad projektowania i negatywnie wpływają na jakość projektu.
Jest jeszcze jedna świetna strona o zapachach kodu na Source Making, którą polecam przeczytać, jeśli masz szansę.
A sposób, w jaki warunkowe mogą prowadzić do zapachów kodu, jest prosty: może zaśmiecać twój kod ogromnym zestawem instrukcji, które zawierają wiele kontroli class_exists.
I to jest problem.
Za każdym razem, gdy wprowadzasz inną zależność do swojego kodu, kończysz dodawanie kolejnego warunkowego sprawdzania, czy klasa jest obecna w aplikacji WordPress.
Uważam, że można to zrobić z pojedynczą zależnością – może nawet dwiema zależnościami – i jeśli pracujesz „wystarczająco wysoko" w swojej architekturze, ale nie jest to sposób na prawidłowe radzenie sobie z tym z wieloma zależnościami ani na niższym poziomie w Twoja wtyczka.
W tym miejscu pojawiają się podakcje WordPress. Możesz zobaczyć listę podakcji w tweecie za pośrednictwem Jana powyżej.
W Kodeksie bbPress znajduje się również oficjalna definicja podakcji :
Te wewnętrzne działania można traktować jako „pod-działania” i pozwalają dodawać lub zmieniać kolejność działań WordPressa, jeśli jest to konieczne dla wtyczek zależnych od bbPress.
Przykład tego możesz zobaczyć w tym pliku.
Jasne, ta definicja jest specyficzna dla bbPress, ale to nie znaczy, że nie ma zastosowania do tego, co robimy w WordPressie.
Przykład: Jeśli kiedykolwiek używałeś do_action do zdefiniowania niestandardowej akcji lub skorzystałeś z haka dostarczonego przez kogoś innego spoza rdzenia WordPressa, to znasz strategię wdrażania podakcji.
Innymi słowy, podakcje WordPressa to po prostu akcje, których możemy użyć do zmiany kolejności, w jakiej nasza wtyczka zależy od innej wtyczki.
Sposób, w jaki to jest zaimplementowane, może się różnić w zależności od kontekstu Twojej pracy, ale najpopularniejszym i najbardziej „poprawnym” sposobem WordPressa na to jest wykorzystanie argumentu priorytetu, kiedy Twoja wtyczka jest ładowana.
Oznacza to, że weź priorytet zależności i upewnij się, że jest ona wcześniejsza niż aktywacja wtyczki.
Istnieją alternatywne metody, które można zastosować, takie jak zmiana zachowania wtyczek, gdy są one aktywowane lub nie, ale jest to poza zakresem tego konkretnego postu i może negatywnie wpłynąć na wrażenia użytkownika (ogólnie WordPressa, nie mniej).
Niezależnie od tego, chodzi o to, że jeśli chodzi o korzystanie z podakcji WordPress, programowanie obiektowe i zarządzanie zależnościami stron trzecich, upewnij się, że decyzje, które podejmujesz, nie uszkodzą projektu Twojego kodu.
Jeśli ma sens sprawdzanie istnienia klasy, okej, ale jeśli bardziej sensowne jest czekanie, aż zestaw klas lub wtyczek zostanie załadowany przed własnym, to podakcje WordPressa prawdopodobnie będą miały większy sens.