Отчёт по проекту

Диаграмма классов

Описание проекта

Этот проект реализует базовую систему управления библиотекой, где можно:

• Хранить и обрабатывать информацию о книгах (бумажных и электронных).
• Регистрировать участников (читателей) и библиотекарей.
• Создавать логику бронирования и уведомления о доступности книг.
• Расширять возможности системы при помощи нескольких важных шаблонов GoF.

В коде прослеживается взаимосвязь классов, необходимых для моделирования работы библиотеки, а также примеры применения стандартных паттернов (Singleton, Factory Method, Observer и Decorator).

Структура каталогов и файлов

1. book.py

   • Класс Category, описывающий категорию (жанр, направление и т. д.)
   • Класс Book, содержащий основные поля и методы для книги (название, автор, ISBN и т. д.).
   • Класс EBook для электронных книг (наследуется от Book).
   • Класс BookFactory (реализует фабричный метод) для создания Book или EBook.

2. member.py

   • Класс Member, описывающий участника библиотеки: ID, имя, email, список уведомлений и заимствованных/забронированных книг.
   • Методы для добавления уведомлений, бронирования и возврата книг.

3. library.py

   • Класс Library, реализующий паттерн Singleton (располагает единым хранилищем: книги, участники, библиотекари).
   • Методы для добавления книг, участников, а также поиска по названию, автору или категории.

4. librarian.py

   • Класс Librarian, отвечающий за управление библиотекой со стороны библиотекаря: добавление книг и участников, регистрация новых библиотекарей и т. д.

5. decorator.py

   • Класс BookDecorator, наследующийся от Book, но не меняющий оригинальный код класса напрямую.
   • Класс Borrowable, расширяющий возможности книги, позволяя заимствовать и возвращать её (реализация паттерна Decorator).

6. main.py

   • Точка входа, где создаётся объект библиотеки, книги, участники и библиотекари.
   • Демонстрация добавления и уведомления участников, а также применения декоратора для книги.

Используемые шаблоны GoF

1. Singleton (класс Library)

• Задача: Гарантировать наличие единственного объекта библиотечного хранилища во всём приложении.
• Реализация: Переопределён метод __new__, чтобы проверять существование экземпляра класса. При первом создании инициализируются коллекции для книг, участников и библиотекарей. Все остальные вызовы создают ссылки на тот же объект.
• Преимущества: Упрощённый доступ к «центральному объекту», который хранит основные ресурсы библиотеки, предотвратит конфликт разных экземпляров.

2. Factory Method (BookFactory)

• Задача: Инкапсулировать логику создания различных типов книг (Book или EBook) в одном месте, убирая необходимость менять основной код при добавлении новых форматов.
• Реализация: Статический метод create_book в BookFactory выбирает нужный класс на основании входного параметра book_type.
• Преимущества: При необходимости расширять ассортимент (например, комиксы, аудиокниги) достаточно добавить ещё один подкласс книги и дополнить фабрику.

3. Observer (книга → участник)

• Задача: Позволить объектам (Member) получать уведомление об изменении состояний других объектов (книги).
• Реализация: Книга хранит список наблюдателей observers (участников). При вызове notify_observers() каждому подписчику отправляется уведомление типа «Книга теперь доступна».
• Преимущества: Упрощённое взаимодействие – члены и книги слабо связаны между собой; книга не должна знать деталей конкретных участников, а лишь вызывать метод уведомления.

4. Decorator (BookDecorator / Borrowable)

• Задача: Расширить функционал класса Book, не изменяя его исходный код.
• Реализация: BookDecorator наследуется от Book, внутри храня ссылку на оригинальный объект. Borrowable добавляет поля и методы, например is_borrowed, borrow() и return_book().
• Преимущества: Даёт возможность «подключать» новые возможности (бронирование, контроль срока аренды и т.д.) к любому объекту книги без изменения самого класса Book.

Обоснование применения шаблонов GoF

1. Singleton упрощает логику монолитного объекта «библиотека» и гарантирует, что всё приложение пользуется одним хранилищем данных (книг, пользователей).
2. Factory Method облегчает добавление новых реализаций книг и упорядочивает код, отвечающий за создание.
3. Observer делает систему уведомлений гибкой: при появлении или освобождении книг библиотека не вмешивается в код участников, а просто вызывает метод notify_observers().
4. Decorator даёт возможность впоследствии расширять поведение книг (например, вести журнал просмотров, учитывать состояние, делать отчёты) без модификации основной логики класса Book.

Заключение

Таким образом, использование нескольких шаблонов проектирования GoF позволило создать гибкую архитектуру системы библиотеки. Комбинация шаблонов Singleton, Factory Method, Observer и Decorator делает код модульным, лёгким в сопровождении и расширении. В результате любой программист при дальнейшем развитии проекта может добавить новые сущности (типы книг, взаимодействия, правила бронирования), не затрагивая уже существующую структуру.