В чем полезность шаблона проектирования Observer, когда вы можете получить те же результаты, не используя его?
Мне известно об использовании наблюдателя шаблона, но на данный момент я вижу, что это бесполезный слой для выполнения операций над объектами наблюдателя, в то время как вы можете выполнять ту же операцию без необходимости использовать этот шаблон проектирования!
Может кто-нибудь поправить меня, если я ошибаюсь, и объяснить, используя конкретный пример, полезность и важность этого шаблона проектирования?
Я вижу, что он предлагает больше организации кода, но когда мне его использовать?
Например, вот реализация шаблона Observer в PHP:
Вот наблюдаемый или предметный класс
// Dès que cet attribut changera on notifiera les classes observatrices.
protected $name;
public function attach(SplObserver $observer)
{$this->observers[] = $observer;
}
public function detach(SplObserver $observer)
{
if (is_int($key = array_search($observer, $this->observers, true)))
{
unset($this->observers[$key]);
}
}
public function notify()
{
foreach ($this->observers as $observer)
{
$observer->update($this);
}
}
public function getName()
{
return $this->name;
}
public function setNom($name)
{
$this->name = $name;
$this->notify();
}
}
Вот наблюдатели, содержащие действия, совершенные при получении уведомления:
<?php
class Observer1 implements SplObserver
{
public function update(SplSubject $obj)
{
echo 'Observer1 has been notified! Nouvelle valeur de l\'attribut <strong>nom</strong> : ', $obj->getName();
}
}
class Observer2 implements SplObserver
{
public function update(SplSubject $obj)
{
echo 'Observer2 a has been notified! Nouvelle valeur de l\'attribut <strong>nom</strong> : ', $obj->getName();
}
}
И вот как мы их используем
$o = new Observee;
$o->attach(new Observer1); // Adding an observer.
$o->attach(new Observer2); // Adding another observer.
$o->setNom('Victor'); // We mmofidy this attribute and the observers have taken the speficified action
Теперь, как вы видите, мне не нужно реализовывать две функции notify () и update (), чтобы заставить наблюдателей предпринять некоторые действия.
Я не вижу, на какую проблему отвечает этот шаблон проектирования.
Решение
Образец Обозревателя умысел как следует:
Определите зависимость «один ко многим» между объектами, чтобы при изменении состояния одного объекта все его иждивенцы уведомлялись и обновлялись автоматически.
Это не так явно, что проблема заключается в ремонтопригодности, но одна из причин, по которой Обозреватель состоит в том, чтобы отделить объекты от его наблюдателей. Это важно в многоуровневых системах, где вам не нужны стабильные классы в зависимости от нестабильных классов (зависимость в неправильном направлении).
Классическое использование Observer — разделение вида модели. Вид (GUI) имеет тенденцию быть нестабильным. То есть со временем потребуется много изменений в коде, потому что:
- пользователи никогда не довольны дизайном,
- Существуют более новые технологии, улучшающие «вид», такие как распознавание видео, распознавание голоса (Siri, OK Google и т. д.), тактильные устройства, 3D-очки и т. д.
- необходимо реализовать «представление» на разных платформах, мобильных устройствах и т. д.
Код модели в этих системах не хочет знать (быть связанным) со всеми этими деталями, поскольку вам, вероятно, придется изменить и код модели, когда ваши пользователи попросят вас изменить представление. Это усложняет обслуживание вашей системы.
Итак, Observer работает, предоставляя модели очень стабильный интерфейс, называемый Observer который не изменится, даже если программное обеспечение, которое его реализует (представления), может сильно измениться. Мне нравится думать об интерфейсе Observer как о дружелюбной (стабильной) маске, за которой скрываются все безумные постоянно меняющиеся представления. Это делает классные модели счастливыми, изолируя их от изменений.
Да, это дополнительный слой, но это стабильный слой модели, который по-прежнему позволяет передавать обновления представлениям (наблюдателям), несмотря на их изменение.
TL; DR Observer интерфейс защищает Subject классы от любых изменений в классах, реализующих Observer, Это облегчает поддержку вашего кода.
Лучший способ оценить Observer не использовать это. Вы можете жить, исправляя свои модели (объекты в шаблоне наблюдателя) каждый раз, когда меняются представления (наблюдатели). Если вы чувствуете боль этих изменений каждый раз, вы можете оценить модель. Это IMO одна из самых больших проблем в изучении паттернов GoF ( страдания от обслуживания Требуется по-настоящему оценить их пользу).
Другие решения
Других решений пока нет …