По поводу именно staticmethod согласен, но декораторы в python, механизм намного более мощный, чем просто реализация паттерна. Это уже специфика реализации и классов, и самих декораторов в пайтоне ( я про @staticmethod, @classmethod, @abstractmethod и тд )
но представьте, что мы используем декоратор cache или log. Каким образом в таком случае нарушается принцип единственной ответственности?
вообще немного не правильно с моей стороны говорить о gof паттернах в контексте функций, поэтому уж лучше рассматривать class decorators в python, вот это как раз «классические» декораторы
А еще в пайтоне, функции это объекты)
ну я не хотел упоминать функции высшего порядка раз мы старались говорить в терминах ООП :)
да, я в курсе что это просто синтаксический сахар, но это не нарушает принцип единственной ответственности, f занимается своим, a staticmethod своим
вы же не говорите, когда оборачиваете объект бизнес-логики кэширующим декоратором, что теперь у объекта 2 ответственности — и кеширование и бизнес логика
так каким образом при оборочивании функции другой функцией нарушается принцип единственной ответственности?
ну вот насчёт «метод подозревает» не могу согласится
при вызове данного метода из клиентского кода мы не знаем декорированный он или нет, точно так же как и при реализации паттерна. сам метод тоже не может получить данных о том, декорируют его или нет
Так каким образом именно метод может узнать декорирован он или нет?
я вижу, и соглашаюсь с Вами, что такое решение для PHP самое простое
и я ведь и написал, что хорошо оно будет работать, если у вас инстанцируются декорируемые объекты в одном месте (контейнер, фабрика, сервис локатор, ...)
В Вашем случае это ControllerFactory
и не я предлагаю портировать джанго, я наоборот считаю это бессмыслынным
простите, справились с чем именно? портированием джанго? или такой реализацией, чтобы не приходилось оборачивать инстанцируемые классы?
На второе я бы взглянул
на самом деле, я отношусь к ним с некоторым подозрением — с одной стороны это удобный инструмент для задач в духе добавления кэширования/логирования и тд. С другой стороны, это создает сложный для отладки код
Но я скорее за то, чтобы они были, чем не были
ну а так с вами согласен, для многих вещей лучше подходит паттерн декоратор, да и go-aop не совсем мне нравится на самом деле
да, я согласен, что в PHP единственной простой альтернативой является декоратор/прокси.
Но везде, где у вас инстанцируется декорируемый класс, Вам придется обернуть этот класс декоратором. И хорошо если у Вас хорошая архитектура и такое место в коде одно :)
но тут разговор идет о портировании джанго в пхп, и я говорил о том, что многие вещи, которые сделаны очень удобно в джанго не будут таковыми в пхп из-за ограничений самого языка и во многом портирование будет бессмыслынным, потому что это по итогу получится подобие Symfony 2/ Laravel 5
это не то, как фреймворк устроен внутри, это то, что он предоставляет для использования, довольно активного использования, и без это во многом теряется его удобство и простота
не совсем, декораторы в Python это фактически реализация паттерна «декоратор» — вы можете обернуть выполнение вашей функции/метода в какой-то декоратор. Например, в django на view функцию можно повесить @login_required и таким образом она будет доступна только для авторизованных пользователей
В PHP так просто сделать не получится (есть решения из области AOP, но это немного не то уже)
А аннотации в доктрине это копия аннотации из Hibernate в Java, и используется немного для другого :)
но представьте, что мы используем декоратор cache или log. Каким образом в таком случае нарушается принцип единственной ответственности?
ну я не хотел упоминать функции высшего порядка раз мы старались говорить в терминах ООП :)
да, я в курсе что это просто синтаксический сахар, но это не нарушает принцип единственной ответственности, f занимается своим, a staticmethod своим
вы же не говорите, когда оборачиваете объект бизнес-логики кэширующим декоратором, что теперь у объекта 2 ответственности — и кеширование и бизнес логика
так каким образом при оборочивании функции другой функцией нарушается принцип единственной ответственности?
А go-aop мне не очень нравится, потому что очень сложный и выглядит реально как борьба с языком
на самом деле это больше мои прихоти, не знаю почему такой большой тред вышел из-за этого)
а как вы решаете вопросы кеширования/логирования? классы-декораторы?
при вызове данного метода из клиентского кода мы не знаем декорированный он или нет, точно так же как и при реализации паттерна. сам метод тоже не может получить данных о том, декорируют его или нет
Так каким образом именно метод может узнать декорирован он или нет?
и я ведь и написал, что хорошо оно будет работать, если у вас инстанцируются декорируемые объекты в одном месте (контейнер, фабрика, сервис локатор, ...)
В Вашем случае это ControllerFactory
и не я предлагаю портировать джанго, я наоборот считаю это бессмыслынным
но я говорю вот о таких декораторах/аннотациях gist.github.com/CHH/4520200
а о библиотеках в духе php annotations я конечно вскурсе
На второе я бы взглянул
в нем вы так же ссылаетесь на декорируемый объект
насчет того, что функция начинает, что-то подозревать тоже наверное не понял вас
но вы правы, что основная цель их в python — это DRY. с их помощью легко можно избавиться от сквозного функционала в духе логирования/кэширования
на самом деле, я отношусь к ним с некоторым подозрением — с одной стороны это удобный инструмент для задач в духе добавления кэширования/логирования и тд. С другой стороны, это создает сложный для отладки код
Но я скорее за то, чтобы они были, чем не были
ну а так с вами согласен, для многих вещей лучше подходит паттерн декоратор, да и go-aop не совсем мне нравится на самом деле
Но соглашусь, что @login_required похож на прокси, так как управляет доступом к субъекту
Но везде, где у вас инстанцируется декорируемый класс, Вам придется обернуть этот класс декоратором. И хорошо если у Вас хорошая архитектура и такое место в коде одно :)
но тут разговор идет о портировании джанго в пхп, и я говорил о том, что многие вещи, которые сделаны очень удобно в джанго не будут таковыми в пхп из-за ограничений самого языка и во многом портирование будет бессмыслынным, потому что это по итогу получится подобие Symfony 2/ Laravel 5
вот пример, как они используются в Django
как вы бы реализовали это в PHP?
docs.djangoproject.com/en/1.8/topics/auth/default/#django.contrib.auth.decorators.login_required
это не то, как фреймворк устроен внутри, это то, что он предоставляет для использования, довольно активного использования, и без это во многом теряется его удобство и простота
В PHP так просто сделать не получится (есть решения из области AOP, но это немного не то уже)
А аннотации в доктрине это копия аннотации из Hibernate в Java, и используется немного для другого :)