Моделът за дизайн на наблюдателя е нещо като подкаст

Ако слушате подкасти, вече сте запознати с модела Observer. Всъщност вие сте „наблюдател“.

Ето определението за модела на наблюдателя:

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

Нека разгледаме определението като свързано с подкасти.

Намерих интересен подкаст, наречен чай за разработчици.

След като щракнете върху бутона SUBSCRIBE, сега съм в списъка им с абонати.

Когато чаят за програмисти пусне нов епизод, приложението ще уведоми мен и други абонати. Той изтегля новия епизод за нас.

Точно това е определението на модела на наблюдателя!

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

Съществува връзка между мнозина за подкасти на разработчиците и абонати.

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

Нека го приложим в Ruby.

Започнете с проста версия.

Класът Podcast съдържа списък от епизоди и има метод за добавяне на_епизод към списъка.

Тогава можем да създадем подкаст developer_tea и да добавим епизод №1 към него така:

Искам да получавам известие, когато излиза нов епизод.

Можем да ме актуализираме след добавяне на нов епизод към списъка:

И винаги, когато получа актуализация от developer_tea, мога да продължа и да изтегля най-новия епизод.

Обичам да слушам developer_tea толкова много, че го препоръчвам на моята приятелка Амбър. Сега Амбър иска да се абонира и за него.

Трябва да сме сигурни, че Амбър също получава известие, когато излиза нов епизод:

Хммм, този код прави това, което искаме.

Но има проблем.

Всеки път, когато искаме да добавим абонат, трябва да предефинираме класа.

Има ли начин за актуализиране на списъка с абонати, без да се налага да дефинирате класа?

Може да поддържаме списък на абонатите!

Новият клас Podcast поддържа списък с абонати с помощта на два нови метода: един за добавяне на абонати и един за премахване на абонати. Когато излиза епизод, ние актуализираме всеки абонат.

За съжаление Амбър не се радва на подкаста толкова, колкото на мен, и решава да се отпише. Използваме метода Remove_subscriber, за да я премахнем от списъка с абонати.

Yay! Току-що научихте модела на наблюдателя!

Принцип на дизайн зад модела на наблюдателя.

Моделът Observer използва принципа на дизайн на Loose Coupling:

Стремете се към слабо съчетани дизайни между взаимодействащи обекти.

Класът Podcast не знае много за своите абонати. Той знае само, че всеки абонат има метод за актуализация.

Тази хлабава връзка свързва до минимум зависимостта между Podcast и неговите абонати. Освен това увеличава гъвкавостта. Стига да има метод за актуализиране, абонат може да бъде всичко: човек, група хора, животно или дори кола.

храна за вкъщи:

  1. Моделът на наблюдателя определя зависимостта между един обект между много, така че когато един обект промени състоянието си, всички негови зависими се известяват и актуализират автоматично.
  2. Принцип на дизайн на свободните съединители: стремеж към слабо свързани конструкции между взаимодействащи обекти.

Благодаря за четенето. Има ли други примери от реалния живот на модела Observer, за който да се сетите?

Публикувам в sihui.io седмично.

Абонирайте се, за да не пропуснете следващата статия от поредицата.

Следващия път ще говорим за ...