Ilekroć mówimy o pewnych koncepcjach programistycznych, myślę, że ważne jest, aby cofnąć się o krok od wszelkich szczegółów, o których rozmawiamy i spojrzeć na sprawy w kontekście szerszego obrazu.
Niektóre moduły wprowadzają efekty uboczne; niektórzy nie. W porządku.
Na przykład wczoraj krótko poruszyłem pomysł programowania efektów ubocznych, ale zrobiłem to, mówiąc o korzystaniu z PSR. A dla tych, którzy po prostu interesują się aspektami programowania w bardziej ogólnym sensie, ważne jest również, aby je zrozumieć.
Pamiętaj, że idea skutków ubocznych , o której mowa w PSR-1, to:
Plik POWINIEN deklarować nowe symbole (klasy, funkcje, stałe itp.) i nie powodować żadnych innych skutków ubocznych lub POWINIEN wykonywać logikę z efektami ubocznymi, ale NIE POWINIEN robić obu.
W tym poście nie jestem tak zainteresowany omawianiem logiki ze skutkami ubocznymi (ponieważ zdarzają się sytuacje, w których efekty uboczne się zdarzają). Zamiast tego jestem bardziej zainteresowany zrozumieniem efektów ubocznych programowania (czym one są, czego należy unikać itd.).
W końcu mówienie o skutkach ubocznych w jednym kontekście może oznaczać jedno, podczas gdy w programowaniu może oznaczać coś innego.
Programowanie skutków ubocznych
Ok, więc cały pomysł lub definicja ogólnego efektu ubocznego jest prosta, prawda?
wtórny, zwykle niepożądany efekt leku lub leczenia medycznego.
Usuń cały aspekt leczenia, a zostaniesz z „drugorzędnym, … niepożądanym efektem". Dobrze, więc oto potencjalnie myląca część:
- decydujemy się dołączyć plik,
- wiemy, co robi plik,
- tak więc, jeśli wiemy, co zawieramy i co robi, jak może wprowadzić coś niepożądanego?
Przynajmniej tak często słyszę to pytanie, jeśli chodzi o mówienie o skutkach ubocznych. W programowaniu zawsze uogólniałem efekty uboczne jako wszystko, co zmienia stan programu.
Wystarczająco łatwe, prawda?
Skutki uboczne w WordPressie
Załóżmy, że pracujesz z WordPressem, ponieważ to właśnie robię i o czym piszę 🙂, a my mamy plik odpowiedzialny za dodanie elementu podmenu do jednego z istniejących menu najwyższego poziomu.
Ta klasa może być stosunkowo prosta, ponieważ zawiera odpowiednie wywołanie API WordPress, jest uruchamiana po dołączeniu do [właściwego] zaczepu, a następnie dodaje podmenu zgodnie z przeznaczeniem.
Ale załóżmy, że albo ta klasa, metoda w klasie, albo dołącza plik, do którego ta klasa dodaje również JavaScript lub style, które zmieniają stan elementu podmenu tak, że jest podświetlony, zachowuje się tak, jakby został „kliknięty” lub robi coś, czego ani program, ani użytkownik nie zamierzają.
Byłby to efekt uboczny, ponieważ zmienia stan programu.
Co powinien zrobić moduł?
Ta klasa sama w sobie powinna zrobić jedną rzecz :
Zasada pojedynczej odpowiedzialności to zasada programowania komputerowego, która stanowi, że każdy moduł lub klasa powinna mieć odpowiedzialność za pojedynczą część funkcjonalności zapewnianej przez oprogramowanie, a odpowiedzialność ta powinna być całkowicie zawarta w klasie.
Ale kiedy wprowadzamy coś, co dodaje do tego, co ma robić – kiedy zwiększamy jego odpowiedzialność lub zmieniamy jedną podstawową rzecz, którą robi – wtedy wprowadziliśmy efekt uboczny.
Pamiętaj, że nie jest to z natury złe (zgodnie z definicją PSR-1 powyżej), ale ważne jest, aby rozpoznać, kiedy to robimy, a kiedy nie.
Jak więc dodać funkcjonalność?
Myślę, że naturalnym pytaniem jest to, że jeśli chcemy dodać funkcjonalność do programu, który zmienia jego stan, jak to robimy (i czy to źle)?
Po pierwsze nie, to nie jest złe. Mam na myśli, że programy mają różne stany w zależności od różnych rzeczy, prawda? Czasami dzieje się tak, gdy coś jest zapisywane na dysku lub w bazie danych; czasami dzieje się tak, gdy użytkownik kliknie element w interfejsie użytkownika i tak dalej.
Ale w jaki sposób te stany się zdarzają, w grę wchodzi natura skutków ubocznych.
Weźmy na przykład pomysł podmenu. Ma robić jedną rzecz. Nie powinno to zmieniać niczego poza tym, co widzimy na ekranie.
- Nie powinien zapisywać do bazy danych,
- Nie powinien ustawiać detektora zdarzeń, gdy inny obiekt doda podmenu,
- Nie powinien zmieniać prezentacji niczego poza sobą.
- I tak dalej.
Dodawanie funkcjonalności działa w ten sam sposób: wprowadzasz klasy, które są odpowiedzialne za wykonanie określonej rzeczy i pozwalasz im to zrobić. Kiedy te komponenty działają w połączeniu ze sobą, masz program funkcjonalny, w którym każdy moduł (klasa/funkcja/cokolwiek) pozostaje na swoim torze, że tak powiem.
Jaka jest zasada kciuka?
Jestem pewien, że wielu z was czytających to ma swoje zdanie na temat tego, jakie są skutki uboczne, a czym nie są. I tak jak ty mam swój własny.
Pomyśl o tym w ten sposób:
Jeśli wywołasz metodę, która zwróci wartość, a następnie ponownie wywołasz metodę z tym samym zestawem danych, powinna ona zwrócić tę samą wartość.
W ten sposób wiesz, że twoja funkcja, klasa lub moduł generyczny nie ma skutków ubocznych.
I jak ze wszystkim, popełniłem te błędy (i prawdopodobnie będę kontynuował), ale jest to kwestia próbowania poprawy w nie robieniu tego.
W końcu stanie się to nową normą.