Дизайнерское решение класса
У меня небольшая дилемма, в которой вы, возможно, поможете мне разобраться.
Сегодня я работал над изменением членства в ASP.NET, чтобы добавить уровень косвенности. По сути, членство в ASP.NET поддерживает пользователей и роли, оставляя все правила авторизации на основе того, принадлежит ли пользователь роли или нет.
Что мне нужно сделать, так это добавить концепцию функции, в которой пользователь будет принадлежать к роли (или ролям), а роль будет иметь одну или несколько связанных с ними функций, что позволит нам авторизовать конкретное действие в зависимости от того, принадлежит ли пользователь. роли, которой назначена функция.
Сказав это, моя проблема не имеет к этому никакого отношения, это проблема дизайна общего класса.
Я хочу предоставить абстрактный метод в моем базовом классе RoleProvider для создания функции (и сохранения ее), но я хочу сделать его необязательным для сохранения описания этой функции, поэтому мне нужно создать свой метод CreateFunction с перегрузкой, один подпись, подтверждающая имя, а другая - принятие имени и описания.
Я могу думать о следующих сценариях:
Создайте обе подписи с модификатором abstract. Проблема заключается в том, что разработчик может не соблюдать передовой опыт, согласно которому одна перегрузка должна вызывать другую с нормализованными параметрами, а логика должна находиться только в последней (той, которая содержит все параметры). Кроме того, нежелательно, чтобы разработчик реализовал оба метода.
Создайте первый как виртуальный, а второй как абстрактный. Вызовите второй из первого, чтобы разработчик мог изменить поведение. У него та же проблема: разработчик может принять "плохие решения", отвергнув его.
То же, что и раньше, но не допускайте переопределения первого (удалите виртуальный модификатор). Проблема здесь в том, что разработчик должен знать, что метод может быть вызван с пустым описанием, и должен обрабатывать эту ситуацию.
Думаю, лучший вариант - третий ...
Как вообще реализуется этот сценарий? Когда вы разрабатываете абстрактный класс, содержащий перегруженные методы. Думаю, это не такая уж редкость ...
Ответы 2
Я считаю, что лучшая комбинация СУХОСТИ и принуждения к контракту выглядит следующим образом (в псевдокоде):
class Base {
public final constructor(name) {
constructor(name, null)
end
public abstract constructor(name, description);
}
или, альтернативно:
class Base {
public abstract constructor(name);
public final constructor(name, description) {
constructor(name)
this.set_description(description)
}
private final set_description(description) {
...
}
}
В Java есть правило, которое поддерживает это решение: «никогда не вызывайте неокончательные методы из конструктора».
Чтобы ответить на первую часть вашего сообщения, ознакомьтесь с AzMan (Диспетчер авторизации), который, кстати, встроен в Windows. Он может указывать операции, которые можно объединить в роли или назначить непосредственно пользователям.
Чтобы ответить на вторую часть вашего вопроса, я бы не стал использовать абстрактный класс. Вместо этого просто предоставьте функциональность в конструкторе и покончите с этим. Кажется, вам нужно указанное поведение, но вы не хотите, чтобы оно менялось. Зачем заставлять потомков предоставлять реализацию.