Refactor group mode switching logic to ensure proper list management
ci / build-backend (push) Successful in 1m36s
ci / build-frontend (push) Successful in 52s
ci / tests (push) Successful in 2m3s
ci / sonar (push) Successful in 6m21s

Updated the Group and UpdateGroupCommandHandler classes to clarify the behavior of group mode switching. The transition to dynamic mode now clears the existing item list to prevent old items from interfering with the new rule-based composition. Enhanced documentation and comments to explain the implications of mode changes. Updated tests to reflect the new behavior, ensuring that the group correctly handles item lists during mode transitions. Localization strings were also updated to inform users about the changes in item management during mode switching.
This commit is contained in:
Leonid Pershin
2026-07-31 04:22:36 +03:00
parent 7163a0b937
commit 375e0a810b
9 changed files with 79 additions and 37 deletions
@@ -34,9 +34,15 @@ public sealed class UpdateGroupCommandHandler(
}
/// <summary>
/// Переход в статический режим материализует вычисленный состав: правило домен не понимает,
/// а группа не должна опустеть от смены режима — на неё уже ссылаются слоты. Обратный переход
/// домен делает сам (список становится закреплённым).
/// Смена режима набора. Домен сбрасывает список позиций — в двух режимах он значит разное,
/// — а прикладной слой достраивает то, чего домену знать не положено.
///
/// В статическом режиме список и есть состав, поэтому переход туда материализует вычисленный
/// правилом: группа не должна опустеть от смены режима — на неё уже ссылаются слоты.
///
/// В динамическом состав считает правило, а список хранит только ручные поправки — и начинается
/// он пустым. Прежние позиции, перенесённые закреплёнными, отменяли бы сам переход: сузить набор
/// правилом было бы нечем.
/// </summary>
private async Task SwitchModeAsync(
Domain.Programming.Group group,
@@ -44,14 +50,14 @@ public sealed class UpdateGroupCommandHandler(
CancellationToken cancellationToken
)
{
if (mode == GroupMode.Dynamic)
{
group.SetMode(mode);
return;
}
// Состав считаем до смены режима: после неё правило уже применяется к пустому списку.
var composition =
mode == GroupMode.Static
? await dynamicResolver.ResolveAsync(group, cancellationToken)
: [];
var composition = await dynamicResolver.ResolveAsync(group, cancellationToken);
group.SetMode(mode);
foreach (var element in composition)
group.AddElement(element.Kind, element.Id);
}
@@ -81,22 +81,24 @@ public class Group
/// Вычисленный правилом состав при переходе в статический режим сюда не переносится: домен
/// правило не интерпретирует. Материализует его вызывающая сторона до смены режима.
/// </summary>
/// <summary>
/// Меняет режим набора. Список позиций при этом **сбрасывается**: в двух режимах он означает
/// разное, и переносить его как есть — значит соврать про то, чем группа стала.
///
/// Прежний состав, оставленный закреплённым, отменял бы саму суть перехода: правило считало бы
/// состав заново, но старые позиции оставались бы в нём навсегда, и «по правилу» на деле
/// означало бы «по правилу плюс всё, что было». Сузить набор правилом стало бы невозможно.
///
/// Обратный переход наполняет список вычисленным составом — это делает прикладной слой: правило
/// живёт там, домен его не интерпретирует.
/// </summary>
public void SetMode(GroupMode mode)
{
if (Mode == mode)
return;
Mode = mode;
if (mode == GroupMode.Dynamic)
{
foreach (var item in _items)
item.SetRole(GroupItemRole.Pinned);
return;
}
_items.RemoveAll(i => i.Role == GroupItemRole.Excluded);
foreach (var item in _items)
item.SetRole(GroupItemRole.Member);
_items.Clear();
}
/// <summary>Записать пересчитанную статистику.</summary>