Как правильно переконструировать классы, чтобы они наиболее соответствовали принципу SRP и нужно ли это в данном случае?

Question

[Леонид ---]

Здравствуйте! Прошу помощи в том, пойдёт ли текущая архитектура для небольшого/среднего проекта в целом, и если имеет место, то может быть что-то исправить, чтобы проект наиболее соответствовал принципам чистой архитектуры - если есть от этого преимущество и действительно есть, что-то что достойно исправления, то милости просим.

Замечания:
1) В модуле ui_service.py у меня есть подозрение, что лучше словарик с объектами методов вынести в отдельный класс.
2) Скорее всего придётся делать интерфейс для TransactionWriteService, если, например, в дальнейшем у нас изменится датакласс в core/entities.py (добавятся новые данные, например).

В целом, если что-то заметили ещё, можете добавить или откорректировать мои замечания.

Репозиторий проекта - https://github.com/xaocit/MyManager.git

Comments

[Telcontar]

Ознакомтесь, пожалуйста, с п 5.12 Правил

Answer 1

[Пума Тайланд]

По словарю в ui_service.py — стоит, и не только его. ControllerWithMethodsOfMenu держит сразу три вещи: таблицу переходов _controller, вывод меню (_menu_main/_menu_view/_menu_edit) и действия (_action_view_direct, _menu_sort). Роутинг (_get_next_menu, _validate_type_of_current_menu) у тебя и так уже в GeneralUi — вынеси ещё и _controller в отдельный класс-конфиг.

С TransactionWriteService мимо — интерфейс тут ни при чём, IRepository и ICreatorOfNewId у тебя и так абстракции. Хрупкость в другом: change_data() пересобирает StructDataOfTransaction целиком из позиционных полей вместо dataclasses.replace(old, **changes). Для add() это вообще не лечится, там нужен полный набор полей на создание.