Kiedy utworzyć niestandardowe centrum NSNotificationCenter?

Question

Grałem z numerem NSNotificationCenter i zastanawiałem się, kiedy można użyć własnego niestandardowego centrum powiadomień, a nie defaultCenter? Jakie byłyby tego zalety?

Przebaczam moją ignorancję, ale wygląda na to, że mogłem z radością dogadać się po prostu używając defaultCenter i nic więcej, ale chcę się upewnić, że nie brakuje mi czegoś istotnego.

Answer 1

dokumentacji Apple jest niejasne, i po prostu stwierdza, że ​​zazwyczaj programista nie będzie musiał tworzyć nowe:

Każdy uruchomiony program, kakao ma centrum domyślnego powiadomienia. Zazwyczaj nie tworzysz własnego. Obiekt NSNotificationCenter może dostarczać powiadomienia tylko w ramach jednego programu.

Pełne źródło: NSNotificationCenter documentation.

Jednak każde centrum powiadomień może obsługiwać sieć powiadomień, rozróżnianych według nazwy i obiektu. Po dodaniu obserwatora zazwyczaj wywołać metodę w jakiś sposób tak:

[center addObserver: self selector: @selector(observe:) name: @"observe" object: someObject]; 

A kiedy piszesz zgłoszenie można określić przedmiot:

[center postNotificationName: @"observe" object: someObject]; 

ten sposób powiedzieć, że używają nazw N i obiekty M, możesz obsługiwać rozróżniane powiadomienia N * M. Myślę, że nie ma potrzeby korzystania z dwóch centrów powiadamiania. Teoretycznie, jeśli skończyłeś wszystkie nazwy, możesz utworzyć inny przy pomocy metody alloc + init, ale prawie nie widzę, jak to się może przydać.

Należy również pamiętać, że centrum powiadomień jest często używane, gdy istnieją dwa obiekty, które nie mają bezpośredniego wskaźnika do siebie (w przeciwnym razie, dlaczego po prostu wywoływanie metody na nim?), Ze względu na unikanie skomplikowanych powiązań (szczególnie podczas korzystania z dużo plików xib), więc posiadanie unikalnego obiektu centrum powiadomień jest bardzo przydatne.

Jeśli zamiast tego korzystasz z centrum powiadomień z parametrem alot + init, musisz upewnić się, że wszystkie obiekty komunikacyjne mają wskaźnik do tego centrum powiadomień, a to może zwiększyć złożoność. Cała moc centrum powiadomień byłaby zmarnowana.

Answer 2

Chociaż jest mocno wykorzystywany w AppKit za pośrednictwem dostępnego singletonu defaultCenter, NSNotificationCenter to tak naprawdę "ogólny mechanizm odsprzęgania". Pozwalając ci na to, że twoje własne instancje są tylko wyrazem tego rodzaju. Jeśli chcesz go użyć do czegoś innego, możesz.

Aby zilustrować za pomocą nieco absurdalnego przykładu, pomyśl o tym w ten sposób: NSDocument ma akcesor windowControllers, który zwraca określone, błogosławione, ważne wystąpienie NSArray, które zawiera odniesienia do wszystkich kontrolerów okien specyficznych dla tego dokumentu. Mimo to NSArray jest po prostu "ogólną strukturą danych list". To, że istnieje ta specjalna instancja w określonym celu, nie oznacza, że ​​ponowne wykorzystanie NSArray do własnych celów może nie być użyteczne. Zarówno NSArray, jak i NSNotificationCenter zapewniają ogólne struktury danych/bloki konstrukcyjne, których specyficzne przykłady są używane w błogosławionych "zawodach" w AppKit, ale oba mogą być użyteczne same.

Podstawowym przypadkiem użycia, jaki widziałem podczas tworzenia autonomicznych instancji NSNotificationCenter, jest sytuacja, w której chcesz uruchomić wiele instancji jakiegoś złożonego podsystemu na wielu wątkach równolegle i nie można ich pomylić z powiadomieniami z wieloma wątkami. W takim przypadku ogólny wzór polega na przydzieleniu jednego centrum NSNotificationCenter na wątek. To powoduje rozdzielenie powiadomień dla każdej sieci obiektów na pojedynczy wątek. Będzie to na ogół wymagane, jeśli obserwatorzy podadzą nil dla parametru obiektu, który chce wysłuchać powiadomień o danej nazwie, niezależnie od źródła.

Wszystko, co powiedziałem, przyznaję, że z mojego doświadczenia wynika, że ​​tworzenie prywatnych instancji NSNotificationCenter jest dość rzadkie.