Dlaczego warto używać niestandardowych zdarzeń zamiast bezpośrednich wywołań metod?

Question

Jestem nowy w programowaniu i sprawdzałem wiele samouczków do kodowania gier. Zauważyłem, że na większości z nich używają zdarzeń niestandardowych do wywoływania metod zamiast wywoływania metody bezpośrednio.

Jakie jest uzasadnienie tej praktyki? Dlaczego po prostu nie nazywają tej metody?

Na przykład:

---

Mamy dwa obiekty: A i B. A ma metodę A.methodA(), która musi zostać użyta, gdy zostanie wywołany warunek B.

Dlaczego wdrożenie:

B wywołuje zdarzenie do A który mówi A uruchomić A.methodA()

zamiast:

B wykorzystuje A.methodA()

Answer 1

Głównym powodem jest oddzielenie interesów. Podczas używania zdarzeń klasa A nie musi wiedzieć o istnieniu klasy B (i vice versa).

Niektóre świadczenia do tego są:

• Znacznie łatwiejsze testowanie jednostkowe (można przetestować klasy A bez klasy B)
• mniejsza szansa na złamanie kodu po zmianie klasy A lub B
• Mniej odniesienia do innych klas w kodzie, co zmniejsza potencjał pamięci przecieki
• Cleaner kod
• Bardziej elastyczne/kod wielokrotnego użytku (kilka innych klas mogli wszyscy słuchają/reagować na zdarzenia z dowolny dodatkowy kod w swoim dyspozytorcie)

Answer 2

Zwykle w większych aplikacjach za pomocą zdarzeń pomaga wszystko abstrakcyjne. Kiedy masz ponad 15 klas i wszystkie są zdarzeniami kontrolującymi ditpatch do kontrolera, dużo łatwiej jest zorientować się, co się dzieje, niż czytać wszystkie części kodu w celu śledzenia funkcji. Korzystanie z wywołań zwrotnych zaczyna tworzyć kod spaghetti.

Jednak bezpośrednie wywołania funkcji będą wykonywane szybciej niż zdarzenia.

Answer 3

Osobiście korzystam z niestandardowych wydarzeń po prostu dla łatwości użytkowania. Mogę jedną klasę wysłać zdarzenie, gdy coś się stanie (powiedzmy, że kończy się animacja lub wystąpi błąd w pobieraniu) i dowolna liczba innych klas uruchamia dowolną liczbę innych funkcji opartych na tym zdarzeniu. Ponadto koduję możliwość ponownego użycia. Celem każdej klasy jest pełna niezależność, dzięki czemu może ona działać w dowolnym projekcie bez potrzeby innych pakietów. Więc zamiast jednej klasy wywołać metodę innej klasy, wysyłam zdarzenie z pierwszej klasy, której słucha druga klasa, a następnie uruchamiam tę metodę. Kiedy potrzebuję tej pierwszej klasy dla innego projektu, mogę po prostu skopiować/wkleić go bez konieczności modyfikacji i bez utraty funkcjonalności.

EDYCJA: Warto również zauważyć, że czasami ludzie robią to, co opisujesz, i przechodzą przez argumenty zdarzeń.

Załóżmy, że masz przycisk na scenie i musisz go kliknąć, ale musisz również móc ręcznie wywołać tę metodę. Niektórzy ludzie nie zdają sobie sprawy, że możesz przekazać wydarzenie zerowe i mieć tylko jedną metodę. Lub można ustawić go jako domyślny argumentu null, patrz poniżej:

private function onClickHandler(e:MouseEvent = null):void{ 
    //as long as you never reference "e" within this method, this method can be used both for MouseEvent listeners and manually calling it elsewhere in the code 
} 

Ta technika może pomóc uniknąć konieczności obsługi zdarzeń, który tylko wywołuje inny sposób i nic innego. W tym momencie w moim programowaniu każda instrukcja obsługi zdarzenia AS3, którą zapisuję, domyślnie ustawia argument zdarzenia na wartość null. Po prostu ułatwia to później.

Answer 4

You might want to read this.

notatkę i również przy użyciu metody wywołania zwrotnego pozwala na przekazywanie parametrów do niego bezpośrednio, a nie za pomocą modelu zdarzeń niestandardowych.

Answer 5

Zbudowałem swój własny, bardzo uproszczony system dyspozytorski zdarzeń. Model zdarzeń AS jest bardzo silny, ale w 99% sytuacji nie potrzebujesz tej mocy. Proste wywołanie zwrotne z parametrami wystrzelonymi jako zdarzenie jest więcej niż wystarczające. Nadal można zachować uniwersalność modelu zdarzeń, ale nie trzeba pisać zbyt wielu linii kodu, powiedzmy, prostego przycisku. mogę skonfigurować prosty wydarzenie tak:

Buttonizer.autoButton(_buttQuit, this, "onPress"); 
public function onPressQuit(c:Sprite) { 
// Execution goes here 
} 

można zbudować własny model zdarzeń, to uczyni życie prostszym, a kod znacznie bardziej zwięzły.