По моему мнению, эта модель больше проблем, чем стоит.
Вместо этого, возможно, вы захотите определить интерфейсы для каждой роли доступа, а затем передать объект по ссылкам на соответствующий тип интерфейса. Скорее всего, это будет гораздо более читабельным и интуитивно понятным, хотя все равно требует, чтобы вы определяли и поддерживали интерфейсы для каждой роли.
Интерфейсы и предоставляемые ими функции-члены должны быть выбраны в соответствии с ролями доступа. Вам не обязательно нужен отдельный интерфейс для каждой функции. Если вы так думаете, я бы воспринял это как кодовый запах и воспринял бы это как сигнал для переоценки дизайна. Это справедливо и при использовании шаблона Attorney-Client / PassKey.
Единственное преимущество шаблона Attorney-Client / PassKey состоит в том, что он не требует, чтобы функции-члены были virtual
. Но весьма вероятно, что затраты производительности виртуальных функций не важны для вашего приложения .
Недостатком является то, что шаблон Attorney-Client / PassKey побуждает вас создавать «интерфейсы» на основе конкретных пользователей (как в определенных классах, которые получают доступ к Secret
). Это создает связь . Лучше думать с точки зрения общих ролей, которые могут быть назначены соответствующим образом.