Как лучше реализовать паттерн обозреватель для связи вида и представления в mvc? Здравствуйте, в целях получения практического опыта решил написать небольшой mvc велосипед. Умные головы и википедия в частности утверждают, что для реализации взаимодействия модели и представления желательно использовать паттерн обозреватель. Встал вопрос стоит ли использовать встроенные интерфейсы SplSubject/SplObserver или использовать свою реализацию, примеры реализаций так же есть в википедии. Исходя из них я пришел к следующим выводам.
В пользу своей реализации говорят:Мне не нужен метод detach, скрипт сам умрет дойдя до конца, это ведь PHPЯ могу лучше уточнить тип передаваемого класса для метода notify() используя Model вместо SplSubject, т.к. другие классы тоже могут реализовать этот интерфейс
Так же в процессе написания возник еще один вопрос. У меня будут статические виды, которым вообще не нужна модель (формы например). Им не нужен метод notify() как таковой. Исходя из этого их вообще не стоит реализовывать как обозревателей и нужно разделить их каким-то образом с видами которым он нужен.

Предыдущий
вопрос Следующий
вопрос

Действительно, использование паттерна наблюдатель (Observer) может быть очень полезным для взаимодействия между моделью и представлением в архитектуре MVC.

Что касается использования встроенных интерфейсов SplSubject/SplObserver или собственной реализации, то здесь нет однозначного ответа. Использование встроенных интерфейсов может упростить ваш код и сделать его более стандартизированным. Однако, если вам не нужен метод detach и вы хотите более гибкую реализацию, то создание собственной реализации Observer может быть хорошим вариантом.

Что касается статических видов, которым не нужна модель, вам действительно не нужно реализовывать их как обозревателей. Вы можете разделить их каким-то образом от других видов, которым нужен метод notify(). Например, вы можете создать два отдельных интерфейса для видов: один для статических видов и один для динамических видов, которым нужен метод notify().

В целом, выбор между использованием встроенных интерфейсов и собственной реализацией зависит от конкретной задачи и предпочтений разработчика. Главное, чтобы ваша реализация была гибкой, понятной и соответствовала принципам архитектуры MVC.