Как отрефакторить повторяющийся код инициализации различных структур в C#

← На главную

При разработке внешних компонент для 1С на языке C# часто возникает ситуация, когда приходится работать с низкоуровневыми библиотеками (SDK), написанными на C++. Такие библиотеки обычно возвращают или принимают множество различных структур. В результате код превращается в нагромождение однотипных блоков if-else или switch, где для каждого типа данных выполняется практически идентичная логика инициализации полей.

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

Постановка проблемы: дублирование логики для разных структур

Рассмотрим ситуацию, когда у нас есть несколько структур (например, struct_A, struct_B, struct_C), имеющих одинаковые названия полей, но не связанных общим интерфейсом или базовым классом. Типичный код выглядит следующим образом:


if (cond1) 
{
    struct_A r;
    r.field1 = "ага";
    r.field2 = false;
} 
else if (cond2) 
{
    struct_B r;
    r.field1 = "ага";
    r.field2 = false;
} 
else 
{
    struct_C r;
    r.field1 = "ага" + "мухоха"; 
    r.field2 = false;
}

Проблема здесь в том, что в C# структуры являются типами значений (Value Types), и мы не можем просто присвоить их переменной общего типа без потери типизации или упаковки (boxing). Проанализируем возможные пути решения.

Решение 1: Использование объектной обертки и паттерн-матчинга

Один из вариантов — использование общего типа object для хранения структуры и применение механизма switch с проверкой типа (Pattern Matching), появившегося в современных версиях C#. Это позволяет локализовать список поддерживаемых типов в одном методе-хелпере.

Рассмотрим пример реализации метода для установки значений полей:


private object _stru_field(AnvizNew.CCHEX_RET_PERSON_INFO_STRU r, string field, object value) 
{
    // Здесь логика установки конкретных полей для типа A
    return null;
}

private object stru_field(object _r, string field, object value = null)
{
    switch (_r) 
    {
        case AnvizNew.CCHEX_RET_PERSON_INFO_STRU r:
            return _stru_field(r, field, value);
        case AnvizNew.CCHEX_EMPLOYEE2UNICODE_INFO_CARDID_7_STRU r:
            return _stru_field(r, field, value);
    }
    return null;
}

Важное замечание: использование object приводит к упаковке (boxing). Структура копируется из стека в кучу, что создает нагрузку на сборщик мусора (GC). Если ваш код обрабатывает тысячи событий в секунду (например, данные с биометрических терминалов), этот метод может замедлить работу приложения.

Решение 2: Реализация общего интерфейса

Самый правильный с точки зрения объектно-ориентированного программирования подход — заставить структуры реализовывать общий интерфейс. Несмотря на то что структуры не поддерживают наследование, они могут реализовывать интерфейсы.


interface ICommonFields 
{
    string field1 { get; set; }
    bool field2 { get; set; }
}

struct struct_A : ICommonFields { ... }
struct struct_B : ICommonFields { ... }

При использовании интерфейса со структурами нужно быть осторожными. Если вы приведете структуру к интерфейсу ICommonFields, она будет упакована. Чтобы избежать упаковки, следует использовать обобщения (Generics) с ограничениями:


void Initialize<T>(ref T r) where T : struct, ICommonFields 
{
    r.field1 = "ага";
    r.field2 = false;
}

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

Решение 3: Использование Source Generators

Если вы используете .NET 5 или выше, вы можете применить Source Generators (Генераторы исходного кода). Это современная альтернатива макросам C++, которой так не хватает многим разработчикам. Генератор во время компиляции анализирует ваш код и автоматически создает необходимые перегрузки методов или вспомогательные классы.

Это позволяет избежать ручного написания switch по типам. Вы просто помечаете структуры атрибутом, а генератор сам создает код для доступа к их полям. Это решение сочетает в себе красоту абстракции и максимальную производительность.

Анализ производительности: Стек против Кучи

Выясним причину, почему разработчики внешних компонент так держатся за структуры. В .NET структуры (Value Types) размещаются в стеке или внутри содержащего их объекта. Это делает их «дешевыми» для выделения и освобождения памяти.

Ключевые отличия, которые нужно учитывать:

Размер: Рекомендуется использовать структуры только для небольших объектов (обычно до 16 байт).
Семантика копирования: При присваивании структуры создается ее полная копия. Если структура большая, это замедлит работу.
Boxing: Приведение int или struct к object или интерфейсу создает объект в куче. Проанализируем ситуацию: если вы случайно упакуете структуру в цикле, производительность упадет в десятки раз.

Продвинутая техника: Explicit Layout (Union)

В контексте работы с SDK (например, Anviz), где разные типы данных могут перекрывать друг друга в памяти, в C# можно использовать явную разметку структуры. Это позволяет создать одну «универсальную» структуру, которая будет интерпретировать одни и те же байты по-разному в зависимости от контекста.


[StructLayout(LayoutKind.Explicit)]
public struct UniversalStruct
{
    [FieldOffset(0)] public struct_A TypeA;
    [FieldOffset(0)] public struct_B TypeB;
}

Используя FieldOffset(0), мы заставляем поля начинаться с одного и того же адреса в памяти. Это позволяет избежать if-else при инициализации базовых полей, если они находятся по одинаковым смещениям.