W pierwszym poście z tej serii opowiedziałem wszystko o tym, jak chciałem zająć się wprowadzeniem do programowania obiektowego w kontekście WordPressa.
Istnieje kilka świetnych zasobów do programowania obiektowego, ale mogą one używać wymyślonych przykładów lub mogą działać zbyt szybko dla tych, którzy dopiero chcą zacząć.
Aby temu zapobiec, myślę, że mówienie o OOP w WordPressie zakotwicza nas w mocnych fundamentach i używanie praktycznych przykładów zawsze będzie lepsze niż używanie ogólnych przykładów, które są trudne do przetłumaczenia na domenę, w której pracujemy.
Dla tych, którzy jeszcze nie dołączyli lub jeszcze nie nadrobili zaległości, pierwszy post dotyczy następujących tematów:
- Analiza obiektowa,
- Określanie rzeczy, które trzeba mieć, a rzeczy, które trzeba mieć,
- I dlaczego jest to trudne?
I od tego będzie ten post.
Programowanie obiektowe: więcej analiz
Wiem: jeśli chodzi o pisanie kodu, pierwszą rzeczą, którą chcemy zrobić, jest usiąść i zacząć pisać kod. Co jest lepsze niż sprawić, by coś się wydarzyło na ekranie?
A kiedy robisz to dla siebie, nie jest to aż tak wielka sprawa, ale kiedy piszesz kod, będzie to:
- utrzymywany przez zespół ludzi,
- na sprzedaż,
- lub dla wszystkich powyższych
To robi różnicę. Ponieważ dobra analiza może prowadzić do dobrej organizacji, która może prowadzić do dobrej konserwacji.
W przeciwnym razie skleisz coś razem do wysyłki i nie będzie się to dobrze skalować z przyszłymi wersjami. I to jest coś, o czym będziemy szczegółowo mówić w całej serii.
Ale jaki jest dobry sposób na podsumowanie dobrej analizy w trzech prostych krokach? Niekoniecznie jest to odpowiedź kuloodporna, ale staramy się to robić, gdy pracujemy nad projektami:
- Upewnij się, że kod robi to, czego chce klient,
- Stosuj dobre praktyki obiektowe,
- Dąż do projektu, który można konserwować.
Wszystko to brzmi dobrze w teorii, ale bez głębszego zagłębiania się w każdą z nich, skąd mamy wiedzieć, czy robimy to dobrze? Innymi słowy, w tym miejscu często znajdujemy książki, zasoby i inne narzędzia, które utrudniają zostanie lepszym programistą zorientowanym obiektowo.
Właśnie tego chcę uniknąć, więc zamierzam zagłębić się w każdy punkt nieco głębiej.
1 Czego chce klient
Często jest to jeden z najtrudniejszych aspektów całego projektu, ponieważ my, jako programiści, mówimy innym językiem klienta.
Nie tylko często używają terminologii, której my byśmy nie używali, ale często myślą, że to, czego chcą na ekranie, jest najlepszym sposobem na zrobienie tego. To sprawia, że próba ich poprawienia brzmi naprawdę protekcjonalnie i źle, prawda?
Mam na myśli, wyobraź sobie, że próbujesz powiedzieć komuś, że wiesz, czego chcesz, a on cię poprawia. Ostrożne radzenie sobie z tym jest czymś, co może zyskać wielką relacyjną sprawiedliwość, ale potrzeba pewnej ilości czasu, aby „wydobyć" to, czego naprawdę chcą, w porównaniu z tym, co mówią, że chcą.
Zagłębimy się w to bardziej w przyszłym poście.
2 praktyki zorientowane na obiekt
Oczywiście wynika to ze znajomości dobrych praktyk obiektowych i to jest coś, co zamierzam omówić.
Wiele osób powie rzeczy używając takich rzeczy jak:
- zasady SOLID,
- dziedzictwo,
- SUCHY kod,
- wstrzykiwanie zależności,
- i tak dalej
Wszystkie są ważne dla przestrzegania dobrych praktyk zorientowanych obiektowo.
I może nie jest to popularne powiedzenie, ale jestem przekonany, że próba używania wszystkich rzeczy przez cały czas nie zawsze jest dobrym pomysłem. Oznacza to, że zdecydowanie nie chcesz, aby kod powtarzał się w całej bazie kodu, ale czy musisz mieć dziedziczenie w swojej bazie kodu?
Nie.
Są chwile, kiedy zasady powinny być stosowane i kiedy można je zignorować. Ale znajomość ich, kiedy najlepiej je wykorzystać i kiedy ich użyć, jest kluczem do prawidłowego stosowania tych praktyk.
3 łatwy w utrzymaniu projekt
Mówiąc najprościej, stosowanie wzorców i zasad do oprogramowania podczas jego pisania znacznie ułatwi jego użytkowanie i utrzymanie w przyszłości.
Ale znowu jest to uzależnione od:
- pełne zrozumienie czego chce klient,
- wiedząc, jakie praktyki istnieją, kiedy je stosować, a kiedy ich unikać.
Aby to wszystko zrobić, musimy przyjrzeć się każdemu punktowi w jego kontekście, zanim cofniemy się o krok, aby spojrzeć na szerszy obraz.
Czego chce klient?
Oczywiście, jeśli chodzi o powyższe trzy punkty, jest sporo do pokonania. Ale jeśli chcesz napisać dobre, łatwe w utrzymaniu oprogramowanie w ramach ekonomii WordPress, ważne jest, aby zrozumieć, jak to wszystko do siebie pasuje.
Więc zamiast skakać do przodu do pisania kodu lub do pracy nad projektem, następną rzeczą, którą przyjrzymy się, jest to, jak wziąć to, czego chce klient, a następnie rozszyfrować to w zestawie wymagań, które pozwolą nam stworzyć zestawienie pracy.
W ten sposób ostatecznie będziemy mieli roboczy dokument tego, czego chce klient i co zamierzamy zbudować, i wszyscy będziemy na tej samej stronie.