Давайте поговорим о темной стороне силы, а именно – о проблемах в использовании контрактов. О тех милых мелочах, которые аккуратно обходятся разработчиками библиотеки и привносят такую немаленькую бочку дегтя в крохотный горшочек меда.
Вступление.
Будем считать, что классический документ по MS Contracts мы читали, поэтому сразу перейдем к такой удобной вещи, как спецификация интерфейсов для контрактного программирования.
http://research.microsoft.com/en-us/projects/contracts/
http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf
Если у нас есть несколько public полей или методов, то один раз задав спецификацию для этих параметров в рамках интерфейса мы сможем использовать подобный контракт для реальных классов без дополнительной писанины. Описав контракт, можно затем его задействовать как удобную палочку-выручалочку.
Например, мы создаем представителя другой стороны:
public class TheDarkLord
{
public string Name { get; set; }
private string SoName { get; set; }
public TheDarkLord(string name, string soName)
{
this.Name = name;
this.SoName = soName;
}
public string ModifyBaseName(string updatedName)
{
this.Name = updatedName;
return this.Name;
}
}
Вполне возможно, что ради будущих темных падованов потребуется использовать описанный класс как базовый. И, чтобы не обременять себя лишними проверками, зададим спецификацию для public раздела, а также дополним проверку и private заодно.
а) опишем интерфейс
б) не забудем на него создать абстрактную реализацию, которая вберет в себя контрактную спецификацию
в) и расширим основной класс поддержкой проверки private раздела
Реализация:
а) интерфейс и ссылка на контрактную реализацию
[ContractClass(typeof(ITheDarkLordContract))]
public interface ITheDarkLord
{
string Name { get; set; }
string ModifyBaseName(string updatedName);
}
б) контрактная спецификация
[ContractClassFor(typeof(ITheDarkLord))]
public abstract class ITheDarkLordContract : ITheDarkLord
{
public string Name
{
get
{
Contract.Ensures(!string.IsNullOrEmpty(Contract.Result<string>()),
"[ITheDarkLordContract] Name of Dark Lord is null or empty.");
return default(string);
}
set
{
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(value),
"[ITheDarkLordContract] Name of Dark Lord is null or empty.");
}
}
public string ModifyBaseName(string updatedName)
{
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(updatedName),
"[ITheDarkLordContract.ModifyBaseName] The new name of Dark Lord is null or empty.");
Contract.Ensures(!string.IsNullOrEmpty(Contract.Result<string>()),
"[ITheDarkLordContract.ModifyBaseName] The updated name of Dark Lord is null or empty.");
return default(string);
}
}
в) измененный ключевой класс, на который мы прицепили интерфейс и проверку private
public class TheDarkLord : ITheDarkLord
{
public string Name { get; set; }
private string SoName { get; set; }
[ContractInvariantMethod]
private void DarkLordVerification()
{
Contract.Invariant(!string.IsNullOrEmpty(SoName));
}
public TheDarkLord(string name, string soName)
{
Contract.Requires<ArgumentException>(!string.IsNullOrEmpty(name));
Contract.Requires<ArgumentException>(!string.IsNullOrEmpty(soName));
this.Name = name;
this.SoName = soName;
}
public string ModifyBaseName(string updatedName)
{
this.Name = updatedName;
return this.Name;
}
}
Интрига сюжета, которая та самая неожиданная…
Все у нас было хорошо до этого момента. А потом мы сделали шаг номер два – использовали описанный класс как производную для:
[ContractClass(typeof(ITheWhiteLordContract))]
public interface ITheWhiteLord : ITheDarkLord
{
string UpdateAllNames(string name, string soName);
}
[ContractClassFor(typeof(ITheWhiteLord))]
public abstract class ITheWhiteLordContract : ITheDarkLordContract, ITheWhiteLord
{
public string UpdateAllNames(string name, string soName)
{
return default(string);
}
}
Вроде все красиво – создали наследника для интерфейса, доработали новый абстрактный класс и попытались скомпилировать. После чего совершенно неожиданно наступили на ограничение номер раз для библиотеки контрактов: мы не можем контрактные классы наследовать от кого-либо, кроме Object… Хлоп – и понятие наследование для контрактных интерфейсов развалилось…
Хорошо, что же нам рекомендуют разработчики? А они поступают просто фантастическим способом: «возьмите абстрактный класс, пропишите в нем спецификацию методов предка»…
[ContractClass(typeof(ITheWhiteLordContract))]
public interface ITheWhiteLord : ITheDarkLord
{
string UpdateAllNames(string name, string soName);
}
[ContractClassFor(typeof(ITheWhiteLord))]
public abstract class ITheWhiteLordContract : ITheWhiteLord
{
public string Name { get; set; }
public string ModifyBaseName(string updatedName)
{
return default(string);
}
public string UpdateAllNames(string name, string soName)
{
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
"[ITheWhiteLordContract.UpdateAllNames] The new name of White Lord is null or empty.");
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
"[ITheWhiteLordContract.UpdateAllNames] The new soname of White Lord is null or empty.");
Contract.Ensures(!string.IsNullOrEmpty(Contract.Result<string>()),
"[ITheWhiteLordContract.UpdateAllNames] The updated name of White Lord is null or empty.");
return default(string);
}
}
Теперь представим, что в базовом классе у нас штук 10-20 полей, которые придется «протаскивать» наверх. А иерархия может быть не из одного слоя, а наследоваться через группу классов. И после этого предложенная рекомендация сродни издевательству.
Что получили?
Варианты с использованием интерфейсов, как точек для будущих Injections, уже срабатывают плохо. Придется убирать наследование в контрактных интерфейсах и описывать вызовы нужных нам объектов как реальных классов.
а) Специфицируем контракт для потомка
[ContractClass(typeof(ITheWhiteLordContract))]
public interface ITheWhiteLord
{
string UpdateAllNames(string name, string soName);
}
[ContractClassFor(typeof(ITheWhiteLord))]
public abstract class ITheWhiteLordContract : ITheWhiteLord
{
public string UpdateAllNames(string name, string soName)
{
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
"[ITheWhiteLordContract.UpdateAllNames] The new name of White Lord is null or empty.");
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
"[ITheWhiteLordContract.UpdateAllNames] The new soname of White Lord is null or empty.");
Contract.Ensures(!string.IsNullOrEmpty(Contract.Result<string>()),
"[ITheWhiteLordContract.UpdateAllNames] The updated name of White Lord is null or empty.");
return default(string);
}
}
б) изменяем наследование для реального класса
public class TheWhiteLord : TheDarkLord, ITheWhiteLord
{
public string UpdateAllNames(string name, string soName)
{
return this.Name;
}
}
И теперь вместо использования интерфейсов, будем использовать доступ к спецификации классов:
было
public class SpaceSheep
{
public ITheDarkLord AbstractLord { get; set; }
}
реализация в виде класса
public class SpaceSheep
{
public TheDarkLord AbstractLord { get; set; }
}
С точки зрения работоспособности системы мы ничего не потеряли. Если у нас есть класс TheWhiteLord, то его легко отнаследовать от темной стороны, получив доступ к нужным свойствам. При этом работоспособность используемых фреймворков, оперирующих IOC – не поменяется. Фактически, мы можем для спецификации зависимостей оперировать любой реализацией – интерфейсами, абстрактными классами или реальными.
Но осадочек остался. Кто мешал создателям Contracts.Library дать нам возможность оперировать интерфейсами не только для проверки допустимых public свойств, но и выстраивать целостную архитектуру наследования. Увы…
На закуску.
Еще одно мелкое неудобство, о котором желательно помнить. Специализация private свойств через ContractInvariantMethod накладывает небольшое ограничение. Поля, которые анализируются в инвариатных методах, должны быть специфицированы в конструкторе. Вот наш класс:
public class TheDarkLord : ITheDarkLord
{
public string Name { get; set; }
private string SoName { get; set; }
[ContractInvariantMethod]
private void DarkLordVerification()
{
Contract.Invariant(!string.IsNullOrEmpty(SoName));
}
...
}
Вот образец его создания:
TheDarkLord lord = new TheDarkLord("James", "Bond");
Если же мы добавим пустой конструктор по умолчанию, то получим предупреждение. Потому что инвариантный метод после выхода из конструктора проверит условия и вернет Exception:
CodeContracts: invariant is false: !string.IsNullOrEmpty(SoName)
И достаточно удобный способ инициализации свойств класса через «отложенное» присвоение не будет работать:
TheDarkLord secondLord = new TheDarkLord() { Name = "James" };
Можно переписать private свойство через дополнительную переменную и проверку при помощи контрактов, отказавшись от инвариантов, но это увеличит объем кода и лишит возможности использовать достаточно мощный и удобный инструмент post-condition verification…
PS. Про выводимые контрактами сообщения даже не заикаюсь. Казалось бы – кто мешает добавить обработчик разборки стэка вызова и генерацию имени автоматически. Но – создатели разрешают использовать лишь статические строки, лишая нас возможности заменить подобного рода код
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
"[ITheWhiteLordContract.UpdateAllNames] The new name of White Lord is null or empty.");
на что-то схожее с
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name),
string.Format("{0} The new name of White Lord is null or empty.",GetCurrentMethod()));
