ПредишенСледващото

По искане на читателите към друга статия на моделите на дизайна посвети модел Наблюдател (Observer). Този дизайн модел е известен още под имената на издръжка (Slave) и от издателя на абоната (от издателя на абоната).

Изпълнението на този модел се използва за наблюдение на състоянието на обектите в системата. Ако състоянието на обектите се променя в хода на жизнения им цикъл, наблюдателят на системата не уведоми другата за тези събития.

В тази статия ще се опитам най-лесна и интуитивна, можете да кажете за този модел и пример за код на Java, изпълнява Observer.

В някои случаи е по-Watcher?

  • Ако един обект е да предава съобщения към други обекти, но не могат или не трябва да знаем за тяхната вътрешна структура;
  • Ако е необходимо да промените други предмети, когато промените един обект;
  • За да се предотврати силните връзки между обектите на системата;
  • За да следите статуса на някои съоръжения на системата;

Наблюдаван (наблюдавани) обект, а по-скоро предмет или са обект, трябва да предостави интерфейс за регистрация и дерегистрация на наблюдатели (слушателите).

Но самите наблюдатели трябва да имат най-малко един отворен метод, чрез който и да бъдат нащрек за промяна на състоянието на пациента. Този метод често е наричан уведоми.

Тъй монитори могат да бъдат доста много, за да се опрости работата с тях, можете да използвате една колекция (събиране на наблюдатели). Приблизително кода използвам в този случай:

Клас EmptyObserver може да бъде полезна в случаите, когато наблюдателят е достатъчно голям брой уведомяват методи. След това с помощта на анонимни класове можете лесно да създавате, необходима за нас "високоспециализирани" Наблюдатели (тези с ограничен брой методи, прилагани) в движение:

След случай на наблюдателите на класа поставени в субекта, за който трябва да се наблюдава. Във всички области на код, където се развива действието ние се интересуваме от този клас, при условие, добавете призив да уведоми съответния метод от колекцията на наблюдатели:

Един класически пример за Observer модел - са класове от Java Swing пакет. Swing модел на наблюдател се използва за слаба взаимозависимост между модел на организация и графичните обекти. уведомява методи се извикват при смяна на цените на имотите, модел и предаване на информация на джунджурии.

Между другото, аз силно препоръчвам да я видят всички Java Swing код. Това е наистина много високо качество, предназначени библиотека.

Какво ще кажете за подкрепа за многонишкова и синхронизация на списък на обектите на уведомление?

За експозицията, поради мъртвите зони не може да постави уведомление, за да заключите този списък ...

1) на уведомление всеки обект има позоваване брой, който когато се добави към списък увеличава и намалява с разстоянието;

2) Работа със списъка контролира от синхронизация примитив;

3) Ако искате да копирате списъка с известия, като Лок, като същевременно увеличава всички обекти референтни картина (най-удобните за използване autopointerov списък на тип ATL :: CComPtr), премахване на заключването и уведомява слушателите в списъка на копия, а след това се намали референтните обвинения.

Ако се съди по примера ви, не виждам никаква разлика между слушателите и обратно повикване-E? Или това е едно и също нещо? proyanite моля този момент нито primerchik да се очертаят различията моля те!

Yarik: Основната разлика от слушател пренабиране, че обратно повикване може да бъде един (или такива, Пиша Делфи, защото нула). слушател'и може да бъде всяко число. Въпреки това, има един протест. Listenery ако много от тях не могат да знаят един за друг. И в телефонния секретар на събитие може да smastryachit верига обаждане (като всеки WinAPI, като SetWindowsHookEx или SetCliboardViewer) ,, а тя ще "знае" по-рано ustenovlennom (предишна) обаждане и е в състояние да доведе до "върха" на йерархията затвори последния регистриран обаждане. Що се отнася до мен, така че идеята за обратно повикване по "роден" от слушателя. Въпреки това, ако само защото очевидно може да контролира: Искам да се нарече последното, на първо място, или в зависимост от условията, не причиняват последващо обратно повикване ( "яде" събитие). В случай на слушателя да се направи подобно нещо не може да бъде. Но събитието влезете в модел слушател е много по-просто: няма временни променливи, няма проблеми с моделите наричат ​​stdcall, cdecl, и т.н. - накратко, skukota.

Свързани статии

Подкрепете проекта - споделете линка, благодаря!