Gdzie deklarować obserwatorów klasy centralnej? |
Gdzie deklarować obserwatorów klasy centralnej? |
30.06.2013, 13:29:34
Post
#1
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Witam.
Mam taki dylemat z zadeklarowaniem obserwatorów klasy RegistrationUserModel
Wywołanie metody attach() w konstruktorze klasy centralnej(podmiotu obserwacji) - jest dobrą praktyką?. Czy może lepiej zadeklarować obserwatorów w kontrolerze aplikacji? |
|
|
30.06.2013, 16:02:50
Post
#2
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Wywołanie metody attach() w konstruktorze klasy centralnej(podmiotu obserwacji) - jest dobrą praktyką? Uważam, że taka praktyka jest... niecodzienna. ; ) Metoda attach() powinno być "zwykłą" metodą klasy podmiotu wywoływaną tylko wtedy, gdy nowy obserwator chce się zarejestrować na listę "paCZających" - i ta metoda powinna go zarejestrować. Szkoda, że nie napisałeś czegoś więcej o swoim projekcie, bo ciężko cokolwiek więcej powiedzieć - no, mogę dodać, że RegistrationObserver wygląda intrygująco [wygląda mi to na high coupling - skąd obserwator pobiera dane? I czy posiada jakieś dane o sobie? Obserwator powinien być całkowicie niezależnym obiektem, który aktualizuje dane (od podmiotu) na których mu zależy]. Ciekawi mnie to, jak rozumiesz wzorzec obserwatora i jak chcesz go zaimplementować do swojej aplikacji. Gdybyś napisał kilka słów o obserwatorach, wtedy łatwiej byłoby ten temat dalej pociągnąć. Napisz może jakich obserwatorów chciałbyś stworzyć i jak ogólnie widzisz działanie swojej aplikacji ze wzorcem obserwatora. |
|
|
30.06.2013, 18:06:49
Post
#3
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Mój projekt to prosta niekomercyjna strona firmowa z możliwością rejestracji na własnym MVC.
Tak sobie wymyśliłem, że warto, by było odprężyć model zajmującą się rejestracją nowych użytkowników. RegistrationUserModel to typowy model, "sprawdź, czy istnieje użytkownik w bazie jak nie, to użyj zarejestrowanego obserwatora ->attach()". W wymienionym przykładzie tą operacją jest przesłanie message do użytkownika o zaistniałym "faux pas". Mój obserwator jest uzależniony od klasy Warning( Registry::register('Warning') - singleton), która zajmuję się przesyłaniem ostrzeżeń klientom, od klas aplikacji. Wiem, że klasa(Warning) mogła, by działać bezpośrednio w klasie RegistrationUserModel, ale chcę poeksperymentować . W przyszłości zamierzam dodać kilka innych obserwatorów np: statystyki,logi itp. Załóżmy, że obserwator w moim przykładzie ma własną logikę i jest niezależnym komponentem systemu, gdzie w takim razie powinna odbywać się rejestracja obserwatorów klasy RegistrationUserModel - jak pisałem wyżyj jest to aplikacja oparta na wzorcu MVC. |
|
|
30.06.2013, 19:10:11
Post
#4
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Hmm, wydaje mnie się, przyjacielu, że chyba sobie troszkę eksperymentujesz z wzorcami. ; )
Wydaje mnie się także, że spoglądasz na wzorzec obserwatora przez pryzmat wzorca MVC. Jeśli chodzi o wzorzec obserwatora, to: 1. W podmiocie powinny znaleźć się: - metody rejestracji oraz usuwania obserwatorów, - metody odpowiedzialne za informowanie obserwatorów o tym, że coś się zmieniło (to na czym zależy obserwatorom, to co obserwują). 2. W podmiocie powinny znaleźć się cenne informacje (np. public variables, które są aktualizowane w jakiś sposó dla obserwatorów - w końcu to nimi są zainteresowani. 3. Podmiot obserwacji oraz obserwatorzy powinni być całkowicie niezależni od siebie, tj. podmiot posiada cenne info dla obserwatorów i informuje ich o tym, ze je ma i że następuje jakiś update danych itp, a obserwatorzy po otrzymaniu "cynku" robią aktualizację danych (np. zastępują swoje wartości wartościami podmiotu) i to za pomocą swoich metod. Musisz się zastanowić, czy w ogóle będzie Ci tutaj potrzebny wzorzec obserwatora. W tym wzorcu obserwatorzy są tak naprawdę oddzielnymi bytami, które są zainteresowane informacjami od podmiotu. Obserwator to obiekt, który podchodzi do podmiotu i mówi mu: "Ej, Zią, słuchaj, jak będziesz wiedział coś o XYZ, to daj mi znać.". Podmiot mówi: "Okay." Powiedzmy, że Podmiot ma jakąś informację, niech to będzie informacja na temat liczby zarejestrowanych użytkowników. Obserwatorzy są tym zainteresowani i czekają na "cynk". Gdy pojawia się nowy obserwator, wtedy wysyła info do Podmiotu o tym, że jest zainteresowany jego informacjami i żeby Podmiot wpisał go na listę, czyli Podmiot wywołuje metodę rejestracji i zapisuje Obserwatora na swoją listę. Załóżmy, że nagle zarejestruje się nowy użytkownik, wtedy skrypt automatycznie zmienia dane Podmiotu o rejestracji, dodaje +1 do infa o zarejestrowanych użytkownikach, a gdy zmienia się wartość, wtedy Podmiot automatycznie wysyła obserwatorom "cynk" o tym, że liczba się zmieniła - podmiot NIE mówi nawet o tym, o ile się zmieniła ta liczba, tylko po prostu daje cynk: "Ej, coś się zmieniło, zajrzyj do mnie". Wtedy Obserwatorzy zaczynają działać ze swoją logiką. Sami za pomocą swoich metod sprawdzają info o zarejestrowanych użytkownikach i aktualizują te dane. Tylko pamiętaj, że podmiot ma różne dane, a każdy obserwator może być zainteresowany czymś innym, także warto jest informować o zmianach danych tylko tych obserwatorów, którzy są zainteresowani takimi danymi. Co do implementacji tego wzorca w Twojej aplikacji - nie znam szczegółów Twojego systemu (logiki działania), także ciężko mi cokolwiek powiedzieć. Głupi nie jesteś, także jak troszkę pogłówkujesz, to z pewnością coś wymyślisz. ; ) Ewentualnie jakbyś chciał powiedzieć coś więcej na temat logiki swojej apki, wtedy moglibyśmy pomyśleć co można tutaj zrobić. Napisz mi o co chodzi z tą rejestracją? Jakimi informacjami o rejestracji są zainteresowani obserwatorzy? Jakie informacje przekazuje im Podmiot? Najlepiej byłoby, gdybyś napisał jak chciałeś zaimplementować ten wzorzec - chodzi oczywiście o komunikację pomiędzy podmiotem i obserwatorami. Jak to widziałeś? Ten post edytował Dejmien_85 30.06.2013, 19:14:16 |
|
|
30.06.2013, 22:20:58
Post
#5
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Nie zawsze interpretacja własnych myśli jest zrozumiała, a więc kod z systemu wzięty.
Ten post edytował q3trm 30.06.2013, 22:27:39 |
|
|
1.07.2013, 07:28:26
Post
#6
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Powinieneś dopieścić obserwatora - on powinien być niezależny, tj. powinien posiadać dane o swoim stanie (podczas tworzenia obiektu obserwatora Podmiot powinien automatycznie nadać jakiś stan obserwatorowi) i aktualizować je od Podmiotu. Oprócz interfejsu Observer powinieneś także stworzyć interfejs szczególny dla danego obserwatora - obserwator powinien tak naprawdę implementować co najmniej dwa interfejsy, tj.
- Interfejs Observer ma zajmować się aktualizacją danych i niczym więcej. - Dodatkowy interfejs lub interfejsy powinny wykonywać wszelkie wymagane dodatkowe akcje (np. wyświetlać dane, przetwarzać je, czy przekazywać gdzieś dalej). Adnotacja: Jeśli obserwator nie ma żadnych dodatkowych funkcji, wtedy oczywiście można pominąć dodatkowe interfejsy - jednak jaki jest wtedy sens bytu takiego obserwatora? Obserwator powinien coś zwracać. ; ) Zapoznaj się dobrze z wzorcem obserwatora i zastanów się dwa razy, czy aby na pewno to jest to, czego potrzebujesz w swojej aplikacji. *wink* Ten post edytował Dejmien_85 1.07.2013, 07:42:35 |
|
|
1.07.2013, 09:41:49
Post
#7
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Powinieneś dopieścić obserwatora - on powinien być niezależny, tj. powinien posiadać dane o swoim stanie (podczas tworzenia obiektu obserwatora Podmiot powinien automatycznie nadać jakiś stan obserwatorowi) i aktualizować je od Podmiotu. Oprócz interfejsu Observer powinieneś także stworzyć interfejs szczególny dla danego obserwatora - obserwator powinien tak naprawdę implementować co najmniej dwa interfejsy, tj. - Interfejs Observer ma zajmować się aktualizacją danych i niczym więcej. - Dodatkowy interfejs lub interfejsy powinny wykonywać wszelkie wymagane dodatkowe akcje (np. wyświetlać dane, przetwarzać je, czy przekazywać gdzieś dalej). Adnotacja: Jeśli obserwator nie ma żadnych dodatkowych funkcji, wtedy oczywiście można pominąć dodatkowe interfejsy - jednak jaki jest wtedy sens bytu takiego obserwatora? Obserwator powinien coś zwracać. ; ) Zapoznaj się dobrze z wzorcem obserwatora i zastanów się dwa razy, czy aby na pewno to jest to, czego potrzebujesz w swojej aplikacji. *wink* Wiadome, że w moim przykładzie observer jest bezsensu, ale dobrze jest czasami zrobić coś w kierunku edukacyjnym . Jeszcze znalazłem lepszy sposób rejestracji obserwatorów w klasie podmiotu obserwacji.
Powyższy przykład wydaje mi się bardziej przejrzystszy. Zawsze można iść na łatwiznę i użyć biblioteki SPL |
|
|
1.07.2013, 09:49:21
Post
#8
|
|
Grupa: Moderatorzy Postów: 36 442 Pomógł: 6290 Dołączył: 27.12.2004 |
Ja obiekty obserwatorów tworze dopiero wtedy gdy potrzeba, czyli np. gdy pojawi sie obiekt obserwowany i rzuca konkretnym eventem.
http://nospor.pl/wzorzec-obserwator.html -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
Wersja Lo-Fi | Aktualny czas: 18.04.2024 - 07:34 |