MFA или Multi-factor authentication – это метод контроля доступа к чему-либо в котором пользователю для получения доступа к информации необходимо предъявить более одного «доказательства механизма аутентификации». В качестве проверки аутентификации используется не только пароль, но и одно/несколько из следующих пунктов:
- Знание — информация, которую знает субъект. Например пароль, ПИН-код, код, контрольное слово и так далее.
- Владение — вещь, которой обладает субъект. Например, электронная или магнитная карта, токен, флеш-память.
- Свойство, которым обладает субъект. Например биометрия, природные уникальные отличия: лицо, отпечатки пальцев (папиллярные узоры), радужная оболочка глаз, последовательность ДНК.
Это способность объектов с одинаковым интерфейсом (или базовым классом) вести себя по-разному в зависимости от конкретного типа объекта, с которым работает программа.С другой стороны. Это же можно сказать и с другой стороны: это свойство, позволяющее использовать объекты разных типов через общий интерфейс, что упрощает разработку и делает код более гибким и переносимым.
Основа заключается в том, что у нас есть базовый класс или интерфейс и может быть множество других потомков, которые могут работать совершенно по другому, но мы со всеми работаем одинаково через базовый класс.
class Animal { public virtual void Speak() { Console.WriteLine("Базовый звук животного"); } } class Dog : Animal { public override void Speak() { Console.WriteLine("Гав"); } } class Cat : Animal { public override void Speak() { Console.WriteLine("Мяу"); } } class Program { static void MakeSound(Animal animal) { animal.Speak(); } static void Main() { Animal a1 = new Dog(); Animal a2 = new Cat(); MakeSound(a1); // Гав MakeSound(a2); // Мяу } }
В этом примере мы создаём три класса - базовый Animal и два потомка - Dog (Собака) и Cat (Кошка). Собака и кошка делают разные звуки, но чуть ниже в методе MakeSound нам всё равно, какого животного нам передали в качестве параметра. Мы просто вызываем метод Speak и звук будет разный, в зависимости от того, какой именно объект мы получили - кошка или собака
Ключевые моменты:
- Основан на наследовании и переопределении методов.
- Может решаться во время выполнения (динамический полиморфизм).
Один из принципов SOLID и это первая буква S в названии принципа - Single Responsibility Principle. Более подробно читаем в Single Responsibility Principle.
Это Liskov Substitution Principle или LSP. Это третья буква в знаменитом сокращении SOLID.
Барбара Лисков заявила, что производные классы должны быть спроектированы так, чтобы их при необходимости можно было заменить своими базовыми классами без потери обратной совместимости.
Смысл в том, что нужно проявлять осторожность при использовании наследования, которое в современном программировании рекомендуют обходить стороной.
Дядюшка Боб (Роберт Мартин) дал очень хорошее определение - функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом
Принцип инверсии зависимостей (Dependency Inversion Principle) - принцип объектно-ориентированного программирования, суть которого состоит в том, что классы должны зависеть от абстракций, а не от конкретных деталей. Используется для минимизации зацепления в компьютерных программах. Может рассматриваться как уменьшение знаний о данных и поведении объекта (и зацепления с ним) до минимума, описанного интерфейсом.
Принцип входит в пятёрку принципов SOLID. Это буква D в этом сокращении. Принцип был выведен в трудах Роберта Мартина.
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Чаще можно увидеть этот принцип в виде сокращения OCP или Open/Closed Principle. Более подробно читаем про этот принцип в Open Closed Principle.
Interface Segregation Principle (ISP) переводится как Принцип разделения интерфейса. Это четвёртая буква в аббревиатуре SOLID.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» (большие) интерфейсы необходимо разделять на более маленькие и специфические, чтобы программные сущности маленьких интерфейсов знали только о методах, которые необходимы им. В итоге, при изменении метода интерфейса не должны меняться программные сущности, которые этот метод не используют.
Кто-то трактует этот принцип как – лучше больше маленьких интерфейсов, чем один маленький. Я предпочитаю больше маленьких интерфейсов, но не уверен, что это правильное объяснение принципа.