Цель работы Целью является демонстрация практического применения принципов SOLID на четырех задачах:

1. разделение God класса обработки изображений
2. выделение валидации товара из модели предметной области, 3.защита почтового отправителя от изменений за счёт абстракции подсистемы журналирования.
3. Кейс хранилищ (Repository) с устранением ветвления по типам.

В данных примерах были следующие задачи:

1. Устранить нарушение едиинественной ответственности в ImageHelper
2. Обеспечить возможность менять правила проверки товара без изменения класса Product (Open/Closed Principle, инверсия зависимостей)
3. В SmtpMailer избравить от зависимости Open/Closed Principle + расширение журналирования
4. Исключить условные конструкции по типам для паттерна Repository и делегировать сохранение специализированным репозитория (Принцип Барбары Лисков, принцип единой ответственности)

Исходные проблемы:

1. God object. Совмещение разнотипных функций внутри одного класса, что приводит к проблемам с усложенением тестированию, изменениями
2. Валидация внутри модели - при изменении сценариев проверки, меняется метод isValid
3. Смена места хранения влечет изменение SmtpMailer

Решение:

1. Разделение ImageHelper: Введены ImageFileManager, ImageProcessor, ImageDatabaseManager, ImageDownloader и фасад ImageService. Каждый класс отвечает за одну область ответственности, Компоненты возможно расширять без изменения других, классы могут зависеть от абстракций (например от интерфейса загрузчика)

2. Валидация Product: Реализована через выделения контакта ProductValudator и две реализации. Product хранит состояние, проверку осуществляют отдельные валидаторы Новое правило - новая реализация валидатора. Используется инверсия зависимостей, посредством зависимости от абстракции валидатора а не от класса

3. SmtpMailer и логирование: Введен Ilogger, реализация FileLogger, DatabaseLogger, ConsoleLogger, плюс создание фабрики LoggerFactory и SMTP Маiler. Таким образрм реализовано OCP и принцип единой ответственности + принцип подстановки Барбары Лисков

4. Единый репозиторий с условными проверками типа сущности в методе save Введён общий реестр соответствий «тип сущности → конкретный репозиторий». Клиентский код выбирает репозиторий не через ветвления, а через обращение к словарю по ключу type(entity). Для запуска добавлены простые репозитории AccountRepository и RoleRepository. Убраны ветвления по типам в прикладной функции сохранения, добавлено логиирование регистрации типа с информацией об ошибке Использованы принципы единой ответственности, подстановки Лисков и OCP

Возможно стоило инкапсулировать реестр в глобальный провайдер.