Я работаю над сервисом, который администрирует пользователей других сервисов (вызовы API). Чтобы упростить добавление сервисов, я создал интерфейс (ServiceInterface), который должен реализовывать каждый сервис. В интерфейсе есть некоторые функции, такие как newUser ($ input), removeUser ($ input), editUser ($ input) … Input представляет собой массив всей информации, необходимой для вызова API (логин, имя, имя, … ).
По сути, интерфейс представляет собой CRUD для пользователей, для групп (пользователи принадлежат к группам) и для разрешений (у пользователей есть разрешение для группы).
Цель состоит в том, чтобы сопоставить вызовы API с действиями, выполненными на моем сервисе. Пример :
Когда я создаю группу на своем сервисе, я хотел бы создать ее на всех сервисах, которые реализуют интерфейс.
Когда я создаю пользователя в своем сервисе, я хотел бы создать того же пользователя только в тех сервисах, которым я дал ему доступ.
Когда я добавляю разрешение для пользователя в моей службе, я хотел бы добавить такое же разрешение для того же пользователя для целевой службы.
Как видите, в зависимости от действия «протокол» бывает разным.
Что я хотел бы сделать, это обернуть этот протокол. Я не хочу видеть эту логику в своем текущем коде (поиск сервисов, к которым у пользователя есть доступ, какое разрешение принадлежит какому сервису, …).
Единственная идея, которая у меня есть (и она мне не очень нравится), — создать класс «Помощник», который будет обрабатывать всю логику.
В моем коде, который создает группу, я бы просто сделал что-то вроде этого: MyHelper :: newGroup ($ group, ..).
Когда я создаю нового пользователя, я делаю что-то вроде MyHelper :: newUser ($ login, $ firstname, …), …
У вас есть идея лучше обернуть всю эту другую логику больше ООП?
Благодарю.
В этой ситуации картина наблюдателя лучший вариант. Для получения подробной информации о шаблоне наблюдателя следуйте:
https://sourcemaking.com/design_patterns/observer
https://en.wikipedia.org/wiki/Observer_pattern
http://www.tutorialspoint.com/design_pattern/observer_pattern.htm
Других решений пока нет …