Igor-kr/Final control/11/TASK.md

Задача 11. Рефакторинг системы управления интернет-магазином

Контекст

Вам достался legacy-код системы управления интернет-магазином, расположенный в файле legacy_shop.py.

Код является абсолютно монолитным: вся логика (регистрация пользователей, авторизация, корзина, оформление заказов, расчёт доставки для разных городов, применение промокодов и админ-отчёты) написана сплошным линейным потоком внутри интерактивного CLI-интерфейса. В программе нет ни одной функции и ни одного класса. При этом код содержит огромное количество дублирования логики (copy-paste), нарушает стандарты PEP 8, не имеет обработки ошибок и сложен в поддержке.

---

Ваша задача:

Провести полный рефакторинг этого кода, разделив его на модули, применив объектно-ориентированное программирование (ООП) и исправив стиль кодирования.

Шаг 1. Анализ и исправление стиля (PEP 8)

• Приведите весь код в соответствие со стандартами PEP 8:
  • Устраните отсутствие пробелов вокруг операторов (например, x=y+z).
  • Исправьте именование переменных на snake_case.
  • Уберите «волшебные числа» и жестко захардкоженные пароли (например, пароль админа), вынеся их в константы или конфигурацию.

Шаг 2. Декомпозиция логики в функции

• Найдите все повторяющиеся и логически обособленные куски кода и вынесите их в отдельные переиспользуемые функции с понятными названиями.
• Особое внимание уделите:
  • Валидации полей при регистрации пользователя (сейчас проверки скопированы для каждого поля отдельно).
  • Расчету стоимости доставки (уберите дублирование формул для 10+ городов, обобщите логику).
  • Применению промокодов (уберите длинный if-elif блок, заменив его на структуру данных/словарь соответствий или единую формулу).
  • Валидации чисел при вводе количества товаров и цен.

Шаг 3. Проектирование ООП-архитектуры

Шаг 3. Проектирование ООП-архитектуры

• Вместо хранения сырых словарей (dict) и глобальных переменных спроектируйте систему классов. Создавайте классы там, где они действительно выгодны (например, там, где необходимо инкапсулировать состояние, защитить данные от некорректного изменения или связать данные с поведением). Подумайте, для каких сущностей достаточно простых структур данных/функций, а для каких необходимы полноценные классы:
  • Product — модель товара (id, название, категория, цена, остаток на складе, sku, производитель).
  • User — модель пользователя. Подумайте над наследованием: например, выделите базовый класс User и наследников Customer (клиент) и Admin (администратор) с разным уровнем прав, если это упростит разграничение доступа.
  • Cart — корзина покупателя, управляющая добавлением товаров, изменением количества и подсчетом промежуточного итога (здесь класс выгоден для управления состоянием).
  • Order — заказ пользователя (детали доставки, примененная скидка, стоимость доставки, итоговая сумма, статус).
  • Database — сервис для работы с файлами базы данных (users.json, products.json, orders.json). Должен инкапсулировать логику чтения и записи.
  • Shop — центральный сервис-фасад, координирующий бизнес-логику магазина.

Шаг 4. Создание модульной файловой структуры

Разделите проект на логические части и файлы. Итоговая структура должна выглядеть следующим образом:

shop/
├── __init__.py
├── models/
│   ├── __init__.py
│   ├── product.py
│   ├── user.py
│   ├── order.py
│   └── cart.py
├── services/
│   ├── __init__.py
│   ├── shop.py
│   └── database.py
├── utils/
│   ├── __init__.py
│   └── validators.py
└── main.py

• В main.py должен остаться только запуск приложения и минималистичный интерактивный CLI-интерфейс, вызывающий методы класса Shop.

Шаг 5. Качество кода и надежность

• Добавьте осмысленные docstring'и ко всем классам, методам и модулям.
• Используйте аннотации типов (type hints) для аргументов функций и возвращаемых значений.
• Добавьте обработку исключений (try-except) в места взаимодействия с файловой системой (загрузка/сохранение БД) и при вводе некорректных данных пользователем.
• Проверка стиля кода: Для проверки соответствия стандартам стиля запустите линтер flake8 в корне проекта:

  flake8 shop/
  

---

Критерии оценки:

1. Работоспособность: после рефакторинга весь функционал приложения (от регистрации до админских отчетов) должен работать точно так же, как в исходном файле.
2. Чистота кода: отсутствие дублирования логики (DRY), понятные имена переменных и методов. Команда flake8 shop/ не должна выводить никаких предупреждений или ошибок.
3. Качество ООП: грамотное распределение ответственности между классами, использование инкапсуляции (скрытие внутренних данных), осмысленное применение ООП.
4. Модульность: логичное разделение кода по файлам в папке shop/.