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

В .NET кэширование в оперативной памяти реализует пакет Microsoft.Extensions.Caching.Memory, входящий в набор .NET Extensions. И поводом для написания этой статьи послужили приключения (с успешным концом), связанные с упомянутым в заголовке интерфейсом ICacheEntry из этого пакета, возникшие при попытке его нестандартного использования.

Но рассказать я хочу не только о той недокументированной засаде, в которую я попал, сделав шаг в сторону от примеров использования из документации. И не только о том, как я из нее выбрался. Дело в том, что при выяснении правильного способа работы с ICacheEntry я наткнулся на довольно необычный приём программирования (он же Design Pattern), который я для себя назвал "Скрытый построитель". И наткнулся я на него в коде библиотек .NET не в первый раз. И я раньше нигде не читал про подобный приём. А потому я решил включить в статью ещё и описание этого приёма. А так как этот приём не специфичен для C#, и его вполне можно использовать и на других языках, то он может быть интересен и тем, кто не работает с C# и .NET.

Введение

Для той задачи, которую мне понадобилось решить — хранения в кэше произвольных объектов — в пакете Microsoft.Extensions.Caching.Memory есть интерфейс IMemoryCache и доступный публично реализующий его класс MemoryCache. В пакете также есть довольно много методов расширения для интерфейса IMemoryCache, которые позволяют добавлять в кэш объекты с разными связанными с ними свойствами, такими, например, как время жизни объекта в кэше. Использование этих методов неплохо документировано, эти методы позволяют решать многие задачи, связанные с кэшированием. Многие — но не все. Кроме того, для использования некоторых из этих методов требуется код, кажущийся излишне громоздким.

Для решения нестандартных задач и уменьшения громозкости у меня возникла мысль использовать методы интерфейса IMemoryCache напрямую. И интерфейс это, вроде бы, позволяет. В этом интерфейсе определен метод CreateEntry, который возвращает интерфейс ICacheEntry к вновь созданному элементу кэша, через который возможен доступ к ключу, значению и прочим свойствам создаваемого элемента. Таким образом, кажется возможным создать элемент кэша и установить его свойства вручную. Но при попытке так сделать меня поджидала, буквально, засада. Причём, в документации о ней нет ни слова.

История

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

   ICacheEntry new_entry = _memoryCache.CreateEntry(key);
   new_entry.SlidingExpiration=_idleTimeout;
   new_entry.AbsoluteExpirationRelativeToNow=_maxLifetime;
   new_entry.Size=1; 
   new_entry.Value=result=new ActiveSession(_rootServiceProvider.CreateScope(), this, Session, _logger, trace_identifier);
   PostEvictionCallbackRegistration end_activesession = new PostEvictionCallbackRegistration();
   end_activesession.EvictionCallback=EndActiveSessionCallback;
   end_activesession.State=trace_identifier;
   new_entry.PostEvictionCallbacks.Add(end_activesession);

В документации подробности работы метода IMemoryCache.CreateEntry не описаны, поэтому код выше основывался на предположении. Предположение состояло в том, что этот метод создает элемент в кэше и возвращает интерфейс ICacheEntry, позволяющий установить затем в нем нужные свойства. Это предположение казалось логичным, даже чуть ли не единственно верным, потому что специального метода сохранения установленных свойств (в том числе — кэшируемого значения) для элемента кэша в интерфейсе ICacheEntry нет. Однако этот код не работает: после вызова CreateEntry счётчик элементов в кэше и не думает увеличиваться, объект в кэше не сохраняется и, соответственно, потом не находится. А так как документация совсем не описывает самостоятельное использование ICaheEntry, пришлось лезть в исходный код пакета.

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

public static TItem Set<TItem>(this IMemoryCache cache, object key, TItem value)
{
    using ICacheEntry entry = cache.CreateEntry(key);
    entry.Value = value;

    return value;
}

Странное — это оператор using: его наличие в начале метода позволяет добавить в конце этого метода в кэш полученный элемент, на который ссылается ICacheEntry. Чудеса? Не совсем. Но чтобы понять, как это работает, нужно вспомнить, что собой представляет оператор using в C#.
Думаю, все, сколь-нибудь активно использующие C#, знакомы с идиомой очищаемых (disposable) объектов и используемым в ней методом Dispose() интерфейса IDisposable (от этого интерфейса, кстати, унаследован интерфейс ICacheEntry, на что я сразу и не обратил внимания).

Эта идиома в C# используется настолько часто, что уже давно разработчики языка добавили в него оператор using, который скрывает детали её использования от глаз пользователя.

using (var variable=expression/*выражение_создающее_объект*/) { 
    /*действия_с_созданным_объектом*/ 
} 

var variable=expression/*выражение_создающее_объект*/;
try {
  /*действия_с_созданным_объектом*/ 
}
finally {
  variable.Dispose();
}

Короче, загадочный using в начале блока с телом метода — это вызов метода Dispose() в конце этого блока для переменной entry из using. Ловко придумано, запутывает замечательно ;-). Осталось только разобраться, как этот вызов Dispose(), предназначенный, вообще-то, для очистки более не используемого объекта, помогает решать задачу сохранения элемента в кэше.

Начать расследование стоит с метода создания элемента кэша MemoryCache.CreateEntry: как оказалось, этот метод создает независимый экземпляр класса CacheEntry — внутреннего класса, реализующего публичный интерфейс ICacheEntry — и возвращает этот интерфейс. Слово "независимый" выше означает, что вновь созданный элемент в список элементов кэша на этой стадии пока что не добавлется.

А просмотр исходного кода метода CacheEntry.Dispose() показывает, что этот метод действительно содержит вызов внутреннего метода MemoryCahe.SetEntry(). Метод же SetEntry(), в полном соответствии со своим названием, добавляет в кэш этот независимый элемент CacheEntry. А если элемент с таким же ключом в кэше уже был, то этот старый элемент удаляется (evict) из кэша с кодом причины удаления EvictionReason.Replaced.

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

Но это ещё не всё, о чём я хотел рассказать.

Шаблон проектирования "Скрытый построитель"

Я уже несколько раз встречал в системных библитеках .NET код, в котором инициализация объекта после его конфигурирования происходит внезапно, в неочевидном месте и неочевидным способом. Например, точно так же в неожиданном месте — при первом обращении к их списку — инициализуются и экземпляры объекта конечной точки (тип которого — класс-наследник Endpoint) в подсистеме маршрутизации ASP.NET Core.

И я увидел в таких примерах ранее не встречавшийся мне прием программирования, он же — шаблон проектирования (Design pattern), который я назвал для себя "Скрытый построитель". Он похож на общеизвестный шаблон "Построитель" (Builder), предназначенный для создания сложных объектов, имеющих сложный набор компонентов-свойств, которые могут быть установлены по-разному. В рамках шаблона "Построитель" для этого создается специальный объект построителя, через который конфигурируются компоненты создаваемого сложного объекта, после чего вызывается метод, создающий этот сложный объект. Такой подход достаточно широко используется в .NET: например, в ASP.NET веб-приложение во всех вариантах его построения (Web Host, Generic Host, WebApplication) строится именно по этому шаблону: создаётся объект построителя (соответственно, WebHostBuilder/HostBuilder/WebApplicationBuilder), производится настройка этого объекта и, наконец, создаётся объект приложения вызовом метода Build построителя.

Так вот, в шаблоне "Скрытый построитель" построение сложного объекта начинается примерно так же: создаётся объект построителя (в нашем случае — независимый CacheEntry) и производится его конфигурирование (в нашем случае — через реализуемый им интерфейс ICacheEntry). А вот само создание объекта производится не явным вызовом специального метода, а некой операцией, от которого такое действие совершенно не ожидается (в нашем случае создание элемента в кэше выполняется, как описано выше, методом Dispose, предназначенным, по идее, совсем для другого).

Где можно использовать приём "Скрытый построитель"? Если осознанно — то, разве что, для написания "чистого непонятного кода": кода, формально соответствующего критериям "чистого кода" от теоретиков, но, при этом, все равно ускользающего от понимания. Такая необходимость возникает, например, при обеспечении job security. Или — для защиты интеллектуальной собственности в открытом коде: применение нетривиального приёма программирования безо всяких намеков на него в документации вполне может быть эффективно использовано для того, чтобы отбить охоту лезть в этот код у желающих странного и пытающихся не ограничиваться небольшим набором рекомендуемых приемов использования, документированных в примерах. Но, вообще-то, код, соответствующий приёму "Скрытый построитель", может быть и дикорастущим — получаться сам по себе в процессе написания: например, потому что так короче. Как обстоит дело в данном случае, я точно не знаю: я не готов тут настаивать на обвинении Microsoft в недобрых намерениях, но я не первый раз наблюдаю подобные сомнительные действия у Microsoft, так что от подозрений избавиться не могу.

Является ли шаблон "Скрытый построитель" "антипаттерном"? Об этом пусть спорят теоретики, меня же такой вопрос не волнует. Но лично для себя я решил избегать использовать этот приём — кроме как в случаях, когда действительно требуется написать именно непонятный код. Но я надеюсь, что мне это делать не придется.

Заключение

В статье рассмотрен правильный (и нетривиальный) способ непосредственного, т.е., без помощи методов расширения, использования итерфейса ICacheEntry для настройки и добавления элементов в кэш.

В процессе поиска этого способа был обнаружен ранее неизвестный мне приём программирования (иначе шаблон проектирования) "Скрытый построитель" (рискну преревести его как "Disguised Builder" design pattern). Рассмотрены аргументы за и против его использования.

PS. Если бы у меня был свой телеграмм-канал, то здесь, как модно у современных авторов Хабра, я оставил бы ссылку на него. Но у меня нет своего телеграмм-канала.
А картинка к посту — это как видит скрытый построитель в процессе работы нейросеть "Кандинский".