Комментарии 7
Спасибо за статью, в целом очень наглядная реализация. Два вопроса:
1) применительно к boto3 почему был выбран resource, который сам является фасадом класса boto3.client, а не собственно сам client. Было это осмысленно, с целью не перегружать статью интерфейсом client или с какой-то другой целью.
В данном случае, наверное, нет ничего плохого в том, чтобы накладывать слой абстракции на слой абстракции, и вы правомерно имеете "полное право" ничего не знать о реализации boto3.resource, но обычно такой подход ведет к рискам багов вызванных ограничениями реализации первой абстракции (resource). Такие баги сложно отслеживать из-за длинных и не явных трейсов и очень некрасиво исправлять, т.к. для обхода ограничений придется обращаться напрямую к родительскому классу и код нашей библиотеки по мере расширения функционала и багфиксов рискует превратиться в спагетти
2) часто (хотя это не какое-то 100% универсальное требование) Фасад как паттерн на уровне требований умеет возвращать экземпляр родителя. Конечно это частично нарушает инкапсуляцию, но позволяет решить ряд проблем быстро и красиво конечному пользователю библиотеки. В том числе приведенную выше - вы просто перекладываете ответственность на решение проблем с ограничениями слоя с автора библиотеки-фасада на пользователя библиотеки.
Спасибо! По вопросам:
Да, все верно, я хотел сосредоточиться на непосредственно реализации фасада и по максимуму упростить взаимодействие с исходной библиотекой. Так что это скорее пример проектирования, чем описание способа работы именно с boto3.
Хорошее замечание, согласен.
Все еще сильно зависит от изначальной задачи и области применения паттерна. По крайней мере на моей практике в разных проектах даже с похожей функциональностью реализация может сильно отличаться. Поэтому в примере я старался поймать баланс между требованиями и простотой.
Где можно посмотреть программу целиком?
реализуем сначала абстрактный класс для объекта хранилища.
Посмотрите на модуль https://docs.python.org/3/library/abc.html
А не проще было остановиться на factory, и не ломать мозг миддлам которые потом это будут дебажить чтобы найти решение таски? А facade оставить в его классической реализации как в wiki. Или это чисто академическое упражнение?
Всё верно, это лишь пример, а не часть реального проекта.
Насчёт factory. Безусловно, у представленного подхода есть свои минусы по сравнению с "фабрикой". Но есть и плюсы, которые я как раз и описываю.
Опять же, статья - не призыв использовать код "как есть", а лишь возможность почерпнуть какие-то идеи при необходимости.
Фасад для python библиотеки