Проверка усвоенного материала

Всего вариантов задания: 5. Ваш номер варианта определяется по формуле: номер зачетки % 5 + 1.

Каждый из вариантов может быть реализован в простом (консольном) вароианте, и усложненном - графическом. За второй можно получить существенно больше баллов и при условии закрытых предыдущих заданий предетендовать на автомат.

При выполнении всех заданий необходимо придерживаться архитектуры MVC.

Вариант 1: Система выбора категорий кэшбеков

Описание задачи: Система автоматически выбирает наиболее выгодную стратегию для выбора категорий кэшбека, предложенных различными банками на начало каждого месяца. Каждый банк может предложить несколько категорий с различными процентами кэшбека, а пользователь может выбрать только определенное количество категорий. Система должна учитывать предпочтения пользователя (например, всегда получать максимальный кэшбек по категории "продукты").

Основные компоненты:

  • Категории кэшбеков: Каждая категория должна иметь наименование, процент кэшбека и возможность для пользователя задать приоритеты.
  • Банки: Каждому банку могут быть присвоены определенные категории, которые он предлагает на текущий месяц.
  • Предпочтения пользователя: Пользователь может установить, какие категории ему наиболее важны (например, "продукты").
  • Алгоритм выбора: На основе предложенных категорий и пользовательских предпочтений, программа должна выбрать наиболее выгодные категории с учетом ограничений на количество выбранных.
  • Экспорт/считывание данных: Возможность загрузки данных о банках и категориях из файлов и сохранения результатов выбора в файл для будущего использования.

Требования к паттернам:

  • Использование паттерна Стратегия для алгоритма выбора категории с кэшбеком.

Вариант 2: Система составления расписания исходя из приоритетов

Описание задачи: Система создает расписание на неделю, с учетом заранее известных мероприятий (например, пары в университете, деловые встречи) и задач, которые нужно выполнить, но которые не имеют четких временных рамок. Каждому мероприятию или задаче можно присвоить приоритет, и система должна запланировать их таким образом, чтобы более важные задачи занимали место в расписании раньше менее важных.

Основные компоненты:

  • Мероприятия: обязательные (например, пары в университете) с фиксированным заренее известным временем.
  • Задачи: с неопределенным временем (например, рабочие задачи).
  • Приоритеты: каждому мероприятию или задаче присваивается приоритет от 1 до 10.
  • Рабочие часы: система учитывает рабочие часы пользователя.
  • Алгоритм составления расписания: программа должна автоматически запланировать задачи с более высоким приоритетом.
  • Экспорт/считывание данных: возможность сохранять расписания и данные о задачах в файл и загружать их для дальнейшего использования.

Требования к паттернам:

  • Использование паттерна Стратегия для алгоритма планирования задач.

Вариант 3: Программа по учету прочитанной литературы и генерации рекомендаций

Описание задачи: Система учета прочитанной литературы, которая позволяет пользователю вводить книги с различными параметрами (название, категория, оценка, статус) и на основе этих данных предлагает новые книги для прочтения. Для предложения рекомендаций используется метод вычисления векторного расстояния между книгами, что позволяет находить книги, схожие по жанрам, авторам или предпочтениям пользователя.

Основные компоненты:

  1. Книги: Каждая книга имеет набор характеристик:
    • Название, категория, оценка, автор, дата прочтения, сложность и т.д.
  2. Рекомендации: Программа должна предложить новые книги на основе анализа предыдущих прочитанных книг.
    • Используются алгоритмы: Косинусное сходство, Евклидово расстояние, Метод ближайших соседей.
  3. Экспорт/считывание данных: Поддержка загрузки базы данных книг из файла (например, JSON, CSV, SQLite).

Требования к паттернам:

  • Использование паттерна Фабричный метод для создания объектов книги.

Вариант 4: Система мониторинга и оповещений о статусе заказов с паттерном Наблюдатель

Описание задачи: Система для интернет-магазина отслеживает изменения статуса заказов и отправляет уведомления клиентам и менеджерам о каждом обновлении. Система поддерживает динамическое добавление подписчиков (клиентов, менеджеров) на уведомления по статусам заказов и обеспечивает обработку разных типов уведомлений в зависимости от ролей подписчиков.

Основные компоненты:

  • Заказы: Каждый заказ имеет уникальный идентификатор и текущий статус (например, "в обработке", "отправлен", "доставлен").
  • Пользователи: Пользователи могут подписываться на уведомления о статусах заказов. У пользователей есть роли (например, "клиент", "менеджер"), и уведомления для разных ролей могут быть разными по содержанию.
  • Оповещения: Когда статус заказа меняется, система должна отправить уведомления всем подписанным пользователям. Уведомления для клиентов содержат минимальную информацию, а для менеджеров — более полную.
  • Подписка на уведомления: Пользователи могут подписываться на уведомления для конкретных заказов или для всех заказов с фильтрацией по статусам.
  • История уведомлений: Система должна хранить историю отправленных уведомлений для каждого заказа.

Требования к паттернам:

  • Паттерн Наблюдатель: Для реализации системы оповещений, где заказ является субъектом, а пользователи — наблюдателями.
  • Паттерн Фабрика: Для создания различных типов уведомлений в зависимости от роли пользователя (клиент, менеджер).

Вариант 5: Система интеграции данных о продуктах из локальных модулей с паттерном Адаптер

Описание задачи: Разработать систему, которая объединяет данные о продуктах из нескольких локальных модулей (файлов или внутренних источников), каждый из которых предоставляет данные в своем формате. Система должна преобразовывать данные из разных форматов в унифицированную структуру для дальнейшей обработки. Используемые модули эмулируют независимые источники данных с различными форматами, предоставляя информацию о продуктах.

Основные компоненты:

  • Продукты: Каждый продукт имеет следующие характеристики:
    • Название (name)
    • Категория (category)
    • Цена (price)
    • Описание (description)
    • Наличие на складе (in_stock)
  • Модули данных:
    • Модуль A возвращает данные в формате массива строк, где каждая строка представляет продукт, разделенный точкой с запятой (;).
    • Модуль B предоставляет данные в формате словаря, где ключи и значения полей отличаются от целевого формата.
    • Модуль C возвращает данные в формате списка объектов, где некоторые поля содержат дополнительные вложенные структуры.
  • Единый формат данных: Все данные должны быть приведены к следующему унифицированному формату:
    • Названия полей: name, category, price, description, in_stock.
    • Цена должна быть представлена в виде десятичного числа.
    • Наличие на складе должно быть булевым значением (true или false).

Необходимо учесть:

  • Проверка корректности данных:
    • Уведомление о пропущенных или некорректных полях (например, отсутствие цены).
    • Пометка строк с ошибками для дальнейшего анализа.
  • Фильтрация данных: Возможность фильтрации продуктов по категории или наличию на складе.
  • Объединение данных: После загрузки данных из всех модулей система должна объединить их в единый набор для вывода.

Требования к паттернам:

  • Паттерн Адаптер: Для преобразования данных из различных модулей в унифицированный формат.