Программирование для интерфейса - использовать их для класса безопасности?

Question

Хорошо, я прочитал вопрос переполнения стека 'Что значит "программировать на интерфейс" и понять это. Я понимаю преимущества использования интерфейсов (по крайней мере, я так думаю). Однако у меня возникла небольшая проблема с применением его к тому, над чем я сейчас работаю, и это будет моей первой реализацией интерфейса.

Я создаю класс для аутентификации пользователей на моем сайте. Я написал это, используя статические методы, чтобы я мог сделать User.Authenticate (имя пользователя, пароль). Для меня это приятно и просто. Заглядывая вперед, будут 3 других типа участников, которые могут аутентифицироваться. Их методы аутентификации будут указывать на разные таблицы и т. Д. Однако им все равно нужно будет проходить аутентификацию, менять свой пароль, при смене паролей для проверки своего секретного вопроса и т. Д. Кажется, это идеальное использование для интерфейса, но у меня есть вопросы, которые заставляют меня задуматься, как именно это сделать.

Типы пользователей: пользователи, врачи, брокеры, работодатели. Для меня каждый класс должен реализовывать интерфейс безопасности, который определяет методы, упомянутые выше.

Кто-нибудь может пролить свет на то, как это сделать, И если мое мышление правильно?

Answer 1

Возможно, вы захотите взглянуть на ASP.NET / Microsoft Membership . Из вашего описания звучит так, будто у вас есть пользователи с разными ролями (врач, брокер и т. Д.).

Answer 2

Я бы переосмыслил ваш дизайн с точки зрения базы данных. Мне кажется, что все эти типы людей практически идентичны с точки зрения аутентификации, за исключением того, что они могут играть разные роли в системе. Я бы предположил, что лучшим способом справиться с этим может быть наличие пользователей и ролей, а не разных таблиц для каждого типа пользователей. Затем вы разделяете функции аутентификации и авторизации на разные классы, но вам потребуется только один класс для аутентификации. Единственный раз, когда вам понадобится второй класс аутентификации, - это если ваши пользователи прошли аутентификацию в разных хранилищах аутентификации (скажем, в SQL или AD, а не только в SQL).

Я знаю, что этот ответ не касается вашего вопроса об интерфейсе, поэтому я добавлю, что я предлагаю предложить вам определить интерфейсы аутентификации (или использовать MembershipProvider), а затем создать класс, который реализует этот интерфейс. Таким образом, он будет легче тестируемым / смоделируемым и обеспечит необходимую основу для распространения на другие хранилища аутентификации в будущем, если вы решите это сделать.

Answer 3

Если у вас есть три разных пользовательских объекта, которые используются для аутентификации пользователей с одинаковыми методами и свойствами, это было бы отличным местом для добавления и взаимодействия с каждым из них и кодирования остальной части взаимодействия через них с этим.

Кейд прав, когда не может применить интерфейс к статическим метондам. Основная причина этого заключается в том, что интерфейс применяется к экземпляру объекта, статический метод которого не является частью.

//Defined Classes
class UserType1 : SecurityInterface
class UserType2 : SecurityInterface
class UserType3 : SecurityInterface

//Use classes
SecurityInterface authentication = GetCorrectUserTypeObject(); //the methds gets the correct UserType object base on who is supposed to authenticate.

authentication.DoAuthenticate(); 

Answer 4

Мне кажется, что пользовательские классы не должны инкапсулировать функциональность безопасности. Каркас безопасности или подсистема должны аутентифицировать пользователей разных типов. При этом, возможно, вы захотите, чтобы подсистема принимала объекты пользователей, которые будут аутентифицированы. Если это так, то, если каждый пользовательский класс реализует ILogon или какой-либо подобный интерфейс, по крайней мере, в качестве «маркерного» интерфейса, позволит вашей среде ограничить классы участников во время разработки.

Хотя, вообще говоря, если бы это не просто маркерный интерфейс, я бы не реализовал интерфейс, реализация которого сама по себе нарушает саму природу архитектуры, которая поддерживает наследование и полиморфизм.

Answer 5

«Программирование на интерфейсе» означает разработку набора методов и свойств, которые являются общедоступной «сигнатурой» функциональности или услуги, предоставляемой классом.

Вы объявляете его как интерфейс, а затем реализуете его в классе, который реализует интерфейс.

Затем для замены класса может использоваться любой другой класс, реализующий интерфейс.

Интерфейс становится контрактом.

Однако это не для статических методов.

Я не уверен, для какой цели служит User.Authenticate(username, password) - возвращает ли оно значение, указывающее, что пользователь аутентифицирован? Что такое неаутентифицированный пользовательский объект?

Возможно, у вас есть какой-то центральный контроллер аутентификации, который аутентифицирует пользователей, а затем возвращает другой класс объектов в зависимости от пользователя. Каждый класс будет реализовывать (или, возможно, вместо этого наследовать от пользовательского класса) пользовательский интерфейс для общей функциональности, а затем расширяться за счет своей специфической функциональности.

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

Answer 6

Все упомянутые вами типы пользователей являются пользователями. Я работал на многих веб-сайтах, у которых был короткий подход, в котором они относились к первому типу пользователей, для которых сайт был написан как «пользователь», и затем любые дополнительные типы пользователей, добавленных позже, просто неловко появлялись.

Мое предложение: не называйте один из ваших типов пользователей "пользователем". Все они пользователи разных типов или ролей.

Answer 7

Безопасность - это сквозная проблема для меня, что означает аспектно-ориентированное программирование.