В мире объектно-ориентированного программирования уже достаточно давно подвергается критике концепция наследования.
Аргументов достаточно много:
- дочерний класс наследует все данные и поведение родительского, что нужно не всегда (а при доработке родительского в дочерний класс вообще попадают данные и поведение, которые не предполагались на момент разработки дочернего);
- виртуальные методы менее производительные, а в случае, если язык позволяет объявить невиртуальный метод, то как быть, если в наследнике нужно его перекрыть (можно пометить метод словом 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<KeySize> Items { get; }
static KeySizes()
{
Items = new ReadOnlyCollection<KeySize>(
(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<IAuthProvider> defaultInstance;
static AuthProviderFactory()
{
defaultInstance = new Lazy<IAuthProvider>(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<RandomNumberGenerator> rng;
static AuthProvider()
{
rng = new Lazy<RandomNumberGenerator>(() => 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<IAuthProvider> defaultInstance;
static AuthProviderFactory()
{
defaultInstance = new Lazy<IAuthProvider>(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).
Методология работы с методами расширения предложена в данной статье.
Продолжение следует.
Автор: sand14
