Переформулировка бонуса-2 в Практической ДЗ-2 (fall-2025)

[nevermorrow]

По предложению @AlbinaBurlova вношу свою версию формулировки бонуса на рефакторинг предложенной мини-архитектуры кода в практическом ДЗ-2.

Основные отличия:

1. Backwards compatibility vs breaking changes

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

2. Добавлено требование об указании типизации во всех сигнатурах - потому что это одна из проблем, которы есть в текущей имплементации (из-за чего, в частности, можно только в конце обнаружить, что оптимизаторы должны получать только численные градиенты).

3. Сделан акцент на реализацию регуляризации через инъекцию функций потерь для всех возможных функций без дублирования кода. В качестве проверки на адеватность архитектуры добавлено требование реализовать регуляризацию Elastic-Net.

4. Удалено требование к функционированию замены лосса - из всего, что мне известно, менять лосс динамически на полпути нигде не требуется, поэтому затачивать архитектуру под это мне кажется не соответствующим логике домена.

Соответствующий этим правилам рефакторинг шаблона для следующего потока закину в соседнем пулл-реквесте.