[Из песочницы] Композиция и интерфейсы02.11.2016 15:48

В мире объектно-ориентированного программирования уже достаточно давно подвергается критике концепция наследования.

Аргументов достаточно много:

дочерний класс наследует все данные и поведение родительского, что нужно не всегда (а при доработке родительского в дочерний класс вообще попадают данные и поведение, которые не предполагались на момент разработки дочернего);
виртуальные методы менее производительные, а в случае, если язык позволяет объявить невиртуальный метод, то как быть, если в наследнике нужно его перекрыть (можно пометить метод словом new, но при этом не будет работать полиморфизм, и использование такого объекта может привести к не ожидаемому поведению, в зависимости от того, к какому типу приведен объект в момент его использования);
если возникает необходимость множественного наследования, то в большинстве языков оно отсутствует, а там, где есть (C++), считается трудоемким;
есть задачи, где наследование как таковое не может помочь — если нужен контейнер элементов (множество, массив, список) с единым поведением для элементов разных типов, и при этом нужно обеспечить статическую типизацию, то здесь помогут обобщения (generics).
и т.д., и т.п.

Альтернативой наследованию являются использование интерфейсов и композиция. (Интерфейсы давно используется в качестве альтернативы множественному наследованию, даже если в иерархии классов активно используется наследование.)

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

А как можно решить эту задачу (отсутствие дублирования кода) в случае композиции и интерфейсов?
Этой теме и посвящена настоящая статья.

Пусть объявлен некоторый интерфейс, и два или более классов, реализующих этот интерфейс. Часть кода реализующая интерфейс, у каждого класса различная, а часть — одинаковая.

Для упрощение рассмотрим частный вариант, когда метод MethodA интерфейса реализован у каждого класса по разному, а метод MethodB — одинаково.

Первым вариантом устранения дублирования кода, который приходит в голову, скорее всего, окажется вариант класса-хелпера со статическими методами, которые в качестве аргументов принимают необходимые переменные, и эти методы вызываются в реализациях метода MethodB разных классов, где в метод-хелпер передаются необходимые значения.

Класс хелпер необязательно реализовывать статическим, можно сделать его и экземплярным классом-стратегией, в этом случае входные данные лучше передать в конструктор стратегии, а не в ее методы.

Предлагаю рассмотреть, как этот подход можно реализовать на конкретном примере, с использованием средств современных языков. В данной статье будет использоваться язык C#. В дальнейшем я планирую написать продолжение с примерами на Java и Ruby.

Итак, пусть нам в проекте необходимо реализовать набор классов позволяющих авторизовать пользователя в системе. Методы авторизации будут возвращать экземпляры сущностей, которые мы будем называть AuthCredentials, и которые будут содержать авторизационную/аутентификационную информацию о пользователе. Эти сущности должны иметь методы вида «bool IsValid ()», которые позволяют проверять действительность каждого экземпляра AuthCredentials.

Шаг 1

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

Создадим в Visual Studio Community 2015 решение (Solution) Windows Console Application, состоящее из четырех проектов:

HelloExtensions — непосредственно консольное приложение, в котором будет вызываться основной код примера, вынесенный в библиотеки (Class Library);
HelloExtensions.Auth — основная библиотека, содержащая интерфейсы, позволяющие продемонстрировать решение задачи, рассматриваемой в данной статье;
HelloExtensions.ProjectA.Auth — библиотека с реализацией интерфейсов, определенных в HelloExtensions.Auth;
HelloExtensions.ProjectB.Auth — библиотека с альтернативной реализаций интерфейсов, определенных в HelloExtensions.Auth.

Шаг 2

Определим в проекте HelloExtensions.Auth следующие интерфейсы. (Здесь и далее — предлагаемые интерфейсы имеют демонстрационный характер, в реальных проектах содержимое интерфейсов определяется бизнес-логикой.)

Интерфейс ICredentialUser — для случая, когда пользователь может авторизоваться в системе по своему логину или иному идентификатору (без возможности анонимной авторизации) и без создания сессии пользователя; в случае успешной авторизации возвращается идентификатор пользователя в базе данных (UserId), в противном случае возвращается null.

using System;

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialUser
    {
        Guid? UserId { get; }
    }
}

Интерфейс ICredentialToken — для случая, когда пользователь может авторизоваться в системе анонимно; в случае успешной авторизации возвращается идентификатор (токен) сессии, в противном случае возвращается null.

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialToken
    {
        byte[] Token { get; }
    }
}

Интерфейс ICredentialInfo — для случая традиционной авторизации пользователя в системе по логину (или иному идентификатору), с созданием сессии пользователя; интерфейс является композицией интерфейсов ICredentialUser и ICredentialToken.

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialInfo : ICredentialUser, ICredentialToken
    {
    }
}

Интерфейс IEncryptionKey — для случая, когда при успешной авторизации в системе возвращается ключ шифрования, с помощью которого пользователь может зашифровать данные перед отправкой их в систему.

namespace HelloExtensions.Auth.Interfaces
{
    public interface IEncryptionKey
    {
        byte[] EncryptionKey { get; }
    }
}

Интерфейс ICredentialInfoEx — композиция из интерфейсов ICredentialInfo и IEncryptionKey.

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialInfoEx : ICredentialInfo, IEncryptionKey
    {
    }
}

Шаг 2.1

Определим в проекте HelloExtensions.Auth вспомогательные классы и другие типы данных. (Здесь и далее — декларации и логика вспомогательных классов имеют демонстрационных характер, логика выполнена в виде заглушек (stubs). В реальных проектах вспомогательные классы определяются бизнес-логикой.)

Класс TokenValidator — предоставляет логику валидации идентификатора токена (например, проверки на допустимость значения, внутреннюю консистентность и существование в множестве зарегистрированных в системе активных токенов).

using System;

namespace HelloExtensions.Auth
{
    public static class TokenValidator
    {
        public const int TokenHeaderSize = 8;

        public const int MinTokenSize = TokenHeaderSize + 32;

        public const int MaxTokenSize = TokenHeaderSize + 256;

        private static bool IsValidTokenInternal(byte[] token)
        {
            int tokenBodySize = BitConverter.ToInt32(token, 0);

            if (tokenBodySize != token.Length - TokenHeaderSize)
                return false;

            // TODO: Additional Token Validation, for ex., searching is active token set

            return true;
        }

        public static bool IsValidToken(byte[] token) =>
            token != null &&
            token.Length >= MinTokenSize &&
            token.Length <= MaxTokenSize &&
            IsValidTokenInternal(token);
    }
}

Класс IdentifierValidator — предоставляет логику валидации идентификатора (например, проверки на допустимость значения и на существование идентификатора в базе данных системы).

using System;

namespace HelloExtensions.Auth
{
    public static class IdentifierValidator
    {
        // TODO: check id exists in database
        private static bool IsIdentidierExists(Guid id) => true;

        public static bool IsValidIdentifier(Guid id) => id != Guid.Empty && IsIdentidierExists(id);

        public static bool IsValidIdentifier(Guid? id) => id.HasValue && IsValidIdentifier(id.Value);
    }
}

Перечисление KeySize — перечень допустимых размеров (в битах) ключей шифрования, с определением внутреннего значения в виде длины ключа в байтах.

namespace HelloExtensions.Auth
{
    public enum KeySize : int
    {
        KeySize256 = 32,
        KeySize512 = 64,
        KeySize1024 = 128
    }
}

Класс KeySizes — перечень допустимых размеров ключей шифрования в виде списка.

using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace HelloExtensions.Auth
{
    public static class KeySizes
    {
        public static IReadOnlyList Items { get; }

        static KeySizes()
        {
            Items = new ReadOnlyCollection(
                (KeySize[])typeof(KeySize).GetEnumValues()
            );
        }
    }
}

Класс KeyValidator — предоставляет логику проверки корректности ключа шифрования.

using System.Linq;

namespace HelloExtensions.Auth
{
    public static class KeyValidator
    {
        private static bool IsValidKeyInternal(byte[] key)
        {
            if (key.All(item => item == byte.MinValue))
                return false;

            if (key.All(item => item == byte.MaxValue))
                return false;

            // TODO: Additional Key Validation, for ex., checking for known testings values

            return true;
        }

        public static bool IsValidKey(byte[] key) =>
            key != null &&
            key.Length != 0 &&
            KeySizes.Items.Contains((KeySize)key.Length) &&
            IsValidKeyInternal(key);
    }
}

Шаг 2.2

Определим в проекте HelloExtensions.Auth класс CredentialsExtensions, предоставляющий методы расширения для определенных выше интерфейсов, декларирующих различные структуры AuthCredentials, в зависимости от способа авторизации в системе.

namespace HelloExtensions.Auth
{
    using Interfaces;

    public static class CredentialsExtensions
    {
        public static bool IsValid(this ICredentialUser user) =>
            IdentifierValidator.IsValidIdentifier(user.UserId);

        public static bool IsValid(this ICredentialToken token) =>
            TokenValidator.IsValidToken(token.Token);

        public static bool IsValid(this ICredentialInfo info) =>
            ((ICredentialUser)info).IsValid() &&
            ((ICredentialToken)info).IsValid();

        public static bool IsValid(this ICredentialInfoEx info) =>
            ((ICredentialInfo)info).IsValid();

        public static bool IsValidEx(this ICredentialInfoEx info) =>
            ((ICredentialInfo)info).IsValid() &&
            KeyValidator.IsValidKey(info.EncryptionKey);
    }
}

Как видим, в зависимости от того, какой интерфейс реализует переменная, будет выбран тот или иной метод IsValid для проверки структуры AuthCredentials: на этапе компиляции всегда будет выбираться наиболее «полный» метод — например, для переменной, реализующей интерфейс ICredentialInfo, будет выбираться метод IsValid (this ICredentialInfo info), а не IsValid (this ICredentialUser user) или IsValid (this ICredentialToken token).

Однако, пока не все так хорошо, и есть нюансы:

Утверждение о выборе при вызове наиболее «полного» метода справедливо, если переменная приведена к своему изначальному типу или наиболее «полному» интерфейсу. А если переменную типа, реализующего интерфейс ICredentialInfo, привести в коде к интерфейсу ICredentialUser, то при вызове IsValid будет вызван метод IsValid (this ICredentialUser user), что приведет к неполной/некорректной проверке структуры AuthCredentials.
Насколько корректно существование одновременно двух методов IsValid (this ICredentialInfoEx info) и IsValidEx (this ICredentialInfoEx info)? Получается, для интерфейса ICredentialInfoEx возможна неполная/некорректная проверка.

Таким образом, в текущем варианте реализации методов расширений отсутствует «полиморфизм» интерфейсов (условно назовем это так).

Поэтому представляется, что интерфейсы различных вариантов структур AuthCredentials и класс CredentialsExtensions с методами расширениями нужно переписать следующим образом.

Реализуем пустой интерфейс IAuthCredentials, от которого будут наследовать атомарные интерфейсы («корневой» интерфейс для всех вариантов структур AuthCredentials).

(Переопределять интерфейсы-композиции при этом не нужно — они автоматически унаследуют IAuthCredentials, также не требуется переопределять такие атомарные интерфейсы, для которых не предполагается создавать самостоятельные реализации — в нашем случае это IEncryptionKey.)

namespace HelloExtensions.Auth.Interfaces
{
    public interface IAuthCredentials
    {
    }
}

using System;

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialUser : IAuthCredentials
    {
        Guid? UserId { get; }
    }
}

namespace HelloExtensions.Auth.Interfaces
{
    public interface ICredentialToken : IAuthCredentials
    {
        byte[] Token { get; }
    }
}

В классе CredentialsExtensions оставим только один открытый (public) метод расширения, работающий с IAuthCredentials:

namespace HelloExtensions.Auth
{
    using Interfaces;

    public static class CredentialsExtensions
    {
        private static bool IsValid(this ICredentialUser user) =>
            IdentifierValidator.IsValidIdentifier(user.UserId);

        private static bool IsValid(this ICredentialToken token) =>
            TokenValidator.IsValidToken(token.Token);

        private static bool IsValid(this ICredentialInfo info) =>
            ((ICredentialUser)info).IsValid() &&
            ((ICredentialToken)info).IsValid();

        private static bool IsValid(this ICredentialInfoEx info) =>
            ((ICredentialInfo)info).IsValid() &&
            KeyValidator.IsValidKey(info.EncryptionKey);

        public static bool IsValid(this IAuthCredentials credentials)
        {
            {
                var credentialInfoEx = credentials as ICredentialInfoEx;
                if (credentialInfoEx != null)
                    return credentialInfoEx.IsValid();
            }

            {
                var credentialInfo = credentials as ICredentialInfo;
                if (credentialInfo != null)
                    return credentialInfo.IsValid();
            }

            {
                var credentialUser = credentials as ICredentialUser;
                if (credentialUser != null)
                    return credentialUser.IsValid();
            }

            {
                var credentialToken = credentials as ICredentialToken;
                if (credentialToken != null)
                    return credentialToken.IsValid();
            }

            return false;
        }
    }
}

Как видим, при вызове метода IsValid, проверки на то, какой интерфейс реализует переменная, теперь выполняется не на этапе компиляции, а во время выполнения (runtime).

Поэтому при реализации метода IsValid (this IAuthCredentials credentials) важно выполнить проверки на реализацию интерфейсов в правильной последовательности (от наиболее «полного» интерфейса к наименее «полному»), для обеспечения корректности результата проверки структуры AuthCredentials.

Шаг 3

Наполним проекты HelloExtensions.ProjectA.Auth и HelloExtensions.ProjectB.Auth логикой, реализующей интерфейсы AuthCredentials из проекта HelloExtensions.Auth и средства работы с реализациями этих интерфейсов.

Общий принцип наполнения проектов:

определяем необходимые интерфейсы, наследующие интерфейсы из HelloExtensions.Auth и добавляющие декларации, специфичные для каждого из проектов;
создаем реализации-заглушки этих интерфейсов;
создаем вспомогательную инфраструктуру с заглушками, предоставляющую API авторизации в некой системе (инфраструктура создается по принципу — интерфейс, реализация, фабрика).

Project «A»
Интерфейсы:

namespace HelloExtensions.ProjectA.Auth.Interfaces
{
    public interface IXmlSupport
    {
        void LoadFromXml(string xml);

        string SaveToXml();
    }
}

using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectA.Auth.Interfaces
{
    public interface IUserCredentials : ICredentialInfo, IXmlSupport
    {
    }
}

using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectA.Auth.Interfaces
{
    public interface IUserCredentialsEx : ICredentialInfoEx, IXmlSupport
    {
    }
}

Реализации интерфейсов:

using System;
using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectA.Auth.Entities
{
    using Interfaces;

    public class UserCredentials : IUserCredentials
    {
        public Guid? UserId { get; set; }

        public byte[] SessionToken { get; set; }

        byte[] ICredentialToken.Token => this.SessionToken;

        public virtual void LoadFromXml(string xml)
        {
            // TODO: Implement loading from XML
            throw new NotImplementedException();
        }

        public virtual string SaveToXml()
        {
            // TODO: Implement saving to XML
            throw new NotImplementedException();
        }
    }
}

Примечание: имена элементов сущности могут отличаться от имен, определенных в интерфейсе; в этом случае необходимо реализовать элементы интерфейса явно (explicitly), обернув внутри обращение к соответствующему элементу сущности.

using System;

namespace HelloExtensions.ProjectA.Auth.Entities
{
    using Interfaces;

    public class UserCredentialsEx : UserCredentials, IUserCredentialsEx
    {
        public byte[] EncryptionKey { get; set; }

        public override void LoadFromXml(string xml)
        {
            // TODO: Implement loading from XML
            throw new NotImplementedException();
        }

        public override string SaveToXml()
        {
            // TODO: Implement saving to XML
            throw new NotImplementedException();
        }
    }
}

Инфраструктура API:

namespace HelloExtensions.ProjectA.Auth
{
    using Interfaces;

    public interface IAuthProvider
    {
        IUserCredentials AuthorizeUser(string login, string password);

        IUserCredentialsEx AuthorizeUserEx(string login, string password);
    }
}

namespace HelloExtensions.ProjectA.Auth
{
    using Entities;
    using Interfaces;

    internal sealed class AuthProvider : IAuthProvider
    {
        // TODO: Implement User Authorization
        public IUserCredentials AuthorizeUser(string login, string password)
            => new UserCredentials();

        // TODO: Implement User Authorization
        public IUserCredentialsEx AuthorizeUserEx(string login, string password)
            => new UserCredentialsEx();
    }
}

using System;

namespace HelloExtensions.ProjectA.Auth
{
    public static class AuthProviderFactory
    {
        private static readonly Lazy defaultInstance;

        static AuthProviderFactory()
        {
            defaultInstance = new Lazy(Create);
        }

        public static IAuthProvider Create() => new AuthProvider();

        public static IAuthProvider Default => defaultInstance.Value;
    }
}

Project «B»
Интерфейсы:

namespace HelloExtensions.ProjectB.Auth.Interfaces
{
    public interface IJsonSupport
    {
        void LoadFromJson(string json);

        string SaveToJson();
    }
}

using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectB.Auth.Interfaces
{
    public interface ISimpleUserCredentials : ICredentialUser, IJsonSupport
    {
    }
}

using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectB.Auth.Interfaces
{
    public interface IUserCredentials : ICredentialInfo, IJsonSupport
    {
    }
}

using HelloExtensions.Auth.Interfaces;

namespace HelloExtensions.ProjectB.Auth.Interfaces
{
    public interface INonRegistrationSessionCredentials : ICredentialToken, IJsonSupport
    {
    }
}

Реализации интерфейсов:

using System;

namespace HelloExtensions.ProjectB.Auth.Entities
{
    using Interfaces;

    public class SimpleUserCredentials : ISimpleUserCredentials
    {
        public Guid? UserId { get; set; }

        public virtual void LoadFromJson(string json)
        {
            // TODO: Implement loading from JSON
            throw new NotImplementedException();
        }

        public virtual string SaveToJson()
        {
            // TODO: Implement saving to JSON
            throw new NotImplementedException();
        }
    }
}

using System;

namespace HelloExtensions.ProjectB.Auth.Entities
{
    using Interfaces;

    public class UserCredentials : IUserCredentials
    {
        public Guid? UserId { get; set; }

        public byte[] Token { get; set; }

        public virtual void LoadFromJson(string json)
        {
            // TODO: Implement loading from JSON
            throw new NotImplementedException();
        }

        public virtual string SaveToJson()
        {
            // TODO: Implement saving to JSON
            throw new NotImplementedException();
        }
    }
}

using System;

namespace HelloExtensions.ProjectB.Auth
{
    using Interfaces;

    public class NonRegistrationSessionCredentials : INonRegistrationSessionCredentials
    {
        public byte[] Token { get; set; }

        public virtual void LoadFromJson(string json)
        {
            // TODO: Implement loading from JSON
            throw new NotImplementedException();
        }

        public virtual string SaveToJson()
        {
            // TODO: Implement saving to JSON
            throw new NotImplementedException();
        }
    }
}

Инфраструктура API:

namespace HelloExtensions.ProjectB.Auth
{
    using Interfaces;

    public interface IAuthProvider
    {
        INonRegistrationSessionCredentials AuthorizeSession();

        ISimpleUserCredentials AuthorizeSimpleUser(string login, string password);

        IUserCredentials AuthorizeUser(string login, string password);
    }
}

using System;
using System.Security.Cryptography;

namespace HelloExtensions.ProjectB.Auth
{
    using Entities;
    using Interfaces;

    internal sealed class AuthProvider : IAuthProvider
    {

        private static readonly Lazy rng;

        static AuthProvider()
        {
            rng = new Lazy(() => RandomNumberGenerator.Create());
        }

        public INonRegistrationSessionCredentials AuthorizeSession()
        {
            const int tokenHeaderSize = 8;
            const int tokenBodySize = 64;
            const int tokenSize = tokenHeaderSize + tokenBodySize;

            var credentials = new NonRegistrationSessionCredentials() { Token = new byte[tokenSize] };

            Array.Copy(BitConverter.GetBytes(tokenBodySize), credentials.Token, sizeof(int));
            rng.Value.GetBytes(credentials.Token, tokenHeaderSize, tokenBodySize);

            // TODO: Put Addition Information into the Token Header
            // TODO: Implement Token Storing in a Session Cache Manager

            return credentials;
        }

        // TODO: Implement User Authorization
        public ISimpleUserCredentials AuthorizeSimpleUser(string login, string password)
            => new SimpleUserCredentials();

        // TODO: Implement User Authorization
        public IUserCredentials AuthorizeUser(string login, string password)
            => new UserCredentials();
    }
}

using System;

namespace HelloExtensions.ProjectB.Auth
{
    public static class AuthProviderFactory
    {
        private static readonly Lazy defaultInstance;

        static AuthProviderFactory()
        {
            defaultInstance = new Lazy(Create);
        }

        public static IAuthProvider Create() => new AuthProvider();

        public static IAuthProvider Default => defaultInstance.Value;
    }
}

Шаг 3.1

Наполним консольное приложение вызовами методов провайдеров авторизации из проектов Project «A» и Project «B». Каждый из методов возвратит переменные некоторого интерфейса, наследующего IAuthCredentials. Для каждой из переменных вызовем метод проверки IsValid. Готово.

using HelloExtensions.Auth;

namespace HelloExtensions
{
    static class Program
    {
        static void Main(string[] args)
        {
            var authCredentialsA =
                ProjectA.Auth.AuthProviderFactory.Default.AuthorizeUser("user", "password");
            bool authCredentialsAIsValid = authCredentialsA.IsValid();

            var authCredentialsAEx =
                ProjectA.Auth.AuthProviderFactory.Default.AuthorizeUserEx("user", "password");
            bool authCredentialsAExIsValid = authCredentialsAEx.IsValid();

            var authCredentialsBSimple =
                ProjectB.Auth.AuthProviderFactory.Default.AuthorizeSimpleUser("user", "password");
            bool authCredentialsBSimpleIsValid = authCredentialsBSimple.IsValid();

            var authCredentialsB =
                ProjectB.Auth.AuthProviderFactory.Default.AuthorizeUser("user", "password");
            bool authCredentialsBIsValid = authCredentialsB.IsValid();

            var sessionCredentials = 
                ProjectB.Auth.AuthProviderFactory.Default.AuthorizeSession();
            bool sessionCredentialsIsValid = sessionCredentials.IsValid();
        }
    }
}

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

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

Отдельно стоит отметить, почему задача в данном примере не реализуется через классическое наследование: сущности в проектах «A» и «B» реализуют функциональность специфичную для каждого из проектов — в первом случае сущности могут (де)сериализовываться из/в XML, во втором — из/в JSON.

Это демонстрационное различие, хотя и оно может встречаться в реальных проектах (в которых различий в сущностях может быть еще больше).

Другими словами, если есть некоторый набор сущностей, пересекающихся по функциональности лишь частично, и это само пересечение имеет «нечеткий характер» (где-то используется UserId и SessionToken, а где-то еще и EncryptionKey), то в создании унифицированного API, работающего с этими сущностями в сфере пересечения их функциональности, помогут методы расширения (extensions methods).

Методология работы с методами расширения предложена в данной статье.

Продолжение следует.

Комментарии (5)

gkislin

2 ноября 2016 в 14:05

0

↑

↓

Картинок маловато… Вот например на тему композиция+делегирование: коротко, жизненно и с картинками:
http://citforum.ru/programming/oop_rsis/glava2_1_10.shtml
lair

2 ноября 2016 в 14:17

+3

↑

↓

(Эмм, полиморфизм через as? Больно же будет, особенно при модификациях.)

На мой взгляд, методы-расширения не стоит считать полноправной ОО-функциональностью в C#, это скорее та его часть, которая идет в функциональную часть. Если у вас есть некий интерфейс, экспонирующий некий (простите) метод, то я хочу иметь возможность этот метод определить в своей реализации этого интерфейса. Решение, когда этот метод внезапно уезжает в расширение, приводит к тому, что я не могу этого сделать.

Просто представьте себе, что я добавил новый наследник от IAuthCredentials. Что нужно сделать, чтобы для него продолжало работать IsValid?
Razaz

2 ноября 2016 в 14:37

+1

↑

↓

Как только вы начали добавлять Ex и Info и плодить тонны интерфейсов — все поехало по швам. Экстеншены тут вообще не к месту.
В процессе аутентификации взаимодействуют аккаунты и креденшалы: IAccount и ICredentials.
IAccount — Сущности, которым разрешено проходить процесс аутентификации.
ICredentials — это набор параметров, секретов и тд., которые предъявляет вызывающая сторона.
ICredentialsValidator — валидирует конкретный тип креденшалов.
Так же некорректно использовать понятие провайдер аутентификации — вы в своей задаче решаете проблему валидации креденшалов, что является частью процесса, а не им самим.
Весь ваш код сводится к набору:
User: IAccount
UsernamePasswordCredentials: ICredentials
TokenCredentials: ICredentials
UsernamePasswordCredentialsValidator: ICredentialsValidator
TokenCredentialsValidator: ICredentialsValidator
Ну и простенький ресолв валидаторов. Заодно валидаторы сразу могут получать ссылки на нужный сторадж и выставлять провалидированный аккаунт в ICredentials.
Расширять можно как угодно.
yar3333

2 ноября 2016 в 15:22

0

↑

↓

Что и требовалось доказать: совсем отказываться от наследования пока рано! :)
Ares_ekb

2 ноября 2016 в 15:33

0

↑

↓

Интересная статья, но очень сложно воспринимать без иллюстраций. На шаге 2 вы определили 5 интерфейсов, 3 хелпера и 1 класс расширений. Мне пришлось их нарисовать, чтобы понять о чём идёт речь, потому что для воображения обычного человека это слишком круто.
Затем, на шаге 2.2 добавили ещё 1 интерфейс и переписали класс расширений с использованием as. Я согласен с lair, что это немного странное решение. А что если появятся ещё интерфейсы? Придётся допиливать этот класс расширений?
Затем на шаге 3 в проекте А добавили ещё 3 интерфейса, 2 реализации, 1 «инфраструктурный» интерфейс, 1 его реализацию и 1 фабрику.
Потом идет проект B, в котором добавляются уже 4 интерфейса, а не 3 как в проекте А. Соответственно 3 реализации, а не 2 как в проекте А. Я не понял чем вызвана эта асимметрия. Ну, и ещё «инфраструктура»: 1 интерфейс, 1 реализация, 1 фабрика.
Итого: 15 интерфейсов, 3 хелпера, 1 класс расширений, 7 классов реализаций, 2 фабрики. Даже нарисовав схему, я не очень понимаю что именно там происходит.
Может быть это решается более простыми способами? Внедрением зависимостей, чтобы не хардкодить варианты через as? Или, например, что вы думаете о примесях (mixin)? Есть интересная статья, правда на примере JavaScript, где примеси рассматриваются как более общий случай наследования, при котором не известен заранее родительский класс. Мне это кажется безумно интересным и по-моему это решает проблемы, описанные в вашей статье. Я писал очень немного про такой подход в этой статье, там есть один пример использования: категория множеств наследуется от абстрактной категории и к ней примешивается поведение полной и колполной категорий.