Аннотации - это хорошо или плохо?

[Фанат]

Вот смотрю я на аннотации и мне кажется, что это какое-то извращение.
Но, как Василь Иваныч, нутром чую, а доказать не могу.

Я проглядел первые ссылки с гугля - все единодушно сходятся на том, что аннотации - зло.
Но тем не мении, Симфони, насколько я вижу, только наращивает их использование. Этому есть какое-то объяснение?

Апдейт
Сорри, я не написал сразу какие аннотации.
Те, которые пишутся в комментах и влияют на поведение кода
http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/index.html
http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/annotations.html
https://habrahabr.ru/post/133270/

Самые распространенные, как я понимаю - это @Security и @Template, плюс те что в доктрине

 

[AnrDaemon]

Аннотации как метод документации или аннотации как замена типизации?

 

[fixxxer]

Я так понимаю, речь идет про Spring-подобные AOP-аннотации.

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

Скажем, в PHPUnit они вполне уместны. Ну или какой-нибудь @transactional на инфраструктурном слое вполне норм. А вот в Doctrine, когда прямо в Entities ими хреначится маппинг - это какая-то хрень, конечно (но в доктрине так совершенно необязательно делать).

Я считаю, что главное - понимать, что это просто код, ничего особенного. Тут легко самому себя обмануть: вроде как подобному коду в этом классе не место, но это же не код, это аннотация. Нифига, это тоже код. Если в этом классе такой код был бы уместен (скажем, вместо аннотации @transactional метод был бы обернут в $db->transaction()), то все нормально. А маппинг прямо в entity выглядит странно в любом виде.

В том же Спринге, на мой вкус, этим слишком увлеклись сейчас, а вот в более ранних версиях выглядело в целом вполне разумно. Симфони, кажется, в ту же сторону идет.

 

[MiksIr]

Думаю он про аннотации как макро-язык и метод конфигурации.

Минусы аннотации в проблемах статического анализа кода, т.е. нужен анализатор (плагин для ide и т.п.) поддерживающий этот тип аннотаций. Впрочем, с конфигами та же проблема.

Тут, думаю, нужно выяснить с чем сравниваем. Если аннотации vs код - это одно, если аннотации vs конфиг - это другое.

Если конфиг, тут вопрос уже в плоскости, что удобнее - конфиг в одном месте или конфиг по месту применения конфига. Например, я не вижу проблем описания сущностей в доктрине через аннотации в простых случаях мапинга. Оно там к месту, имхо.

Если же сравнивать с кодом (ну т.е. аннотации как пред условие) - ну, в большинстве случаев код предпочтительнее, имхо, но it depends. Например, при описании rest api и автогенерации доки банальное `@Security("has_role...` или какое-то `@ParamConverter` дает не только аутентификацию, но и актуальность документации. Проанализировать статически код, что бы построить верную документацию - сложная задача.

 

[fixxxer]

Например, я не вижу проблем описания сущностей в доктрине через аннотации в простых случаях мапинга. Оно там к месту, имхо.

А ты можешь заранее гарантировать, что в проекте будет только простой маппинг?
А если будет сложный, то часть в аннотациях, а часть в xml/yaml?

Но вообще мне это не нравится по другой причине - сам подход к написанию entites с Doctrine-аннотациями склоняет к анемичности моделей.

 

[fixxxer]

Если конфиг, тут вопрос уже в плоскости, что удобнее - конфиг в одном месте или конфиг по месту применения конфига.

Бывает, что граница "конфиг-код" не совсем очевидна. Аннотации могут склонить к выбору конфига там, где стоило бы выбрать код. В результате излишняя декларативность может навредить гибкости проекта.

 

[Adelf]

Ну в явах и сишарпах аннотации являются естественной частью языка. И в PHP они приходят очевидно оттуда. Другое дело, что там из всех аннотаций мне нравятся только единицы. Там(в сишарпах) народ слишком увлекается также... Такое мальчишеское - вона, я только аннотациями рулю всем кодом
Мне нравятся явовые @NotNull, @Nullable - но они лишь пытаются заткнуть дыру в синтаксисе языка, и до сих пор стандартом вроде не стали.
В Сишарпах единственное где мне более-менее нравится - это методы в контроллерах

[HttpPost]
public ActionResult<...> add()

Показывает что оно будет обрабатывать POST запрос. Без этого там вообще все плохо было бы. Но это все мелочи.

Но вообще мне это не нравится по другой причине - сам подход к написанию entites с Doctrine-аннотациями склоняет к анемичности моделей.

Вот это самое оно. У C# Entity Framework есть все возможности юзать его как датамаппер и более-менее неанемично писать. Но они туда пихают аттрибуты к каждому свойству. Описывающие как это в базе данных будет лежать [Unique] так и [MaxLength] всякий. И самое страшное, что один и тотже атрибут, Required, MaxLength будет использоваться как для генерации таблицы базы данных, так и для валидации данных после HTTP запроса. И народ активно создаёт Entity прямо из HTTP запросов, минуя любую логику. Это очень вредная вещь.

 

[MiksIr]

А ты можешь заранее гарантировать, что в проекте будет только простой маппинг?
А если будет сложный, то часть в аннотациях, а часть в xml/yaml?

Ну в общем да, оценить развитие проекта хотя бы на год могу. А там или падишах сдохнет или код все-равно рефакторить глобально. Если у нас 99% простого мапинга и 1% сложного, которого нельзя решить на уровне вьюшек, то проблем выноса его в конфиг не вижу тоже. Это не та проблема, на которой стоит собираться консилиуму программистов и долго решать.

Но вообще мне это не нравится по другой причине - сам подход к написанию entites с Doctrine-аннотациями склоняет к анемичности моделей.

Угу, а короткие юбки склоняют к изнасилованию.

 

[MiksIr]

Бывает, что граница "конфиг-код" не совсем очевидна. Аннотации могут склонить к выбору конфига там, где стоило бы выбрать код. В результате излишняя декларативность может навредить гибкости проекта.

В случае необходимости в конкретном месте убираешь аннотацию и заменяешь кодом. Профит. Где потеря гибкости?

 

[Фанат]

Аннотации как метод документации или аннотации как замена типизации?

Не только типизации. Оно тут вообще везде.
Я проапдейтил пост, добавив ссылки. В частности пост на хабре, который описывает, как создавать свои кастомные аннотации с брекджеком и всем причитающимся.

 

[WMix]

к счастью или сожалению в php аннотации это комментарий и может быть полностью проигнорирован, оставив только логику.
если осознать какую работу они совершают, то хочется их больше, а читать комментарии которые являются "активным" кодом извращение еще то. но да проблема - ide

я за аннотации

 

[grigori]

Аннотации - это вставки кода на другом языке.

В PHP нет встроенных механизмов вставок стороннего кода, поэтому используют комментарии.
Вместо @depends в тестах можно было бы написать массив для описания связей. Не так наглядно, поэтому PHPUnit парсит комменты и компилирует макросы. Хорошо ли это? Вставки кода - обычная практика в компилируемых языках. В PHP это реализовано плохо, и я избегаю этого как только можно.

Макросы в С мне нравятся. Если сделать в PHP возможность создания блоков кода на сторонних движках, в первую очередь появятся блоки на JS. Будет ли это хорошо - я не знаю.

 

[MiksIr]

И народ активно создаёт Entity прямо из HTTP запросов, минуя любую логику. Это очень вредная вещь.

Извини, а если у меня CRUD, задача которого фактически в изменении содержимого базы, и проект этот на месяц - чисто данные вбить, мне тоже десять прослоек присобачить?

 

[Adelf]

Извини, а если у меня CRUD, задача которого фактически в изменении содержимого базы, и проект этот на месяц - чисто данные вбить, мне тоже десять прослоек присобачить?

CRUD ты можешь делать как угодно. Мы говорим о тех проектах, где логика есть.

Аннотации - это вставки кода на другом языке.

В PHP нет встроенных механизмов вставок стороннего кода, поэтому используют комментарии.

В каком это языке аннотации - "это вставки кода на другом языке"?

 

[grigori]

В каком это языке аннотации - "это вставки кода на другом языке"?

В PHP. Вставки кода на языке доктрины и симфони. Эти вставки кода компилируются в PHP. Скомпилированный код лежит в папке cache. Его надо чистить при изменениях, например, роутинга, чтобы перекомпилировался.

 

[Sufir]

Извини, а если у меня CRUD, задача которого фактически в изменении содержимого базы, и проект этот на месяц - чисто данные вбить, мне тоже десять прослоек присобачить?

Зачем в таком проекте доктрина? Есть же куча AR решений, которое и получается по сути. На Yii гораздо проще и быстрее такой проект наговнякать, чем симфони и доктрину тащить.

 

[Adelf]

Не. Тут отличий почти нет, кроме именованных параметров конструктора. Во всех языках с аннотациями это выглядит так

/**
* @ParamConverter("post", class="SensioBlogBundle:post")
* @Template("SensioBlogBundle:post:show.html.twig", vars={"post"})
*/
public function showAction(Post $post)

=>

В мета-данных этого метода есть массив аннотаций:
[
new ParamConverter("post", "SensioBlogBundle:post"),
new Template("SensioBlogBundle:post:show.html.twig", ["post"])
]

Да. симфони немного добавили удобств...

 

[MiksIr]

Мы говорим о тех проектах, где логика есть.

"Мы" - это кто? Нигде не видел переключателя "говорим о: дерьмомагазинах / системах управления полетами НАСА"

 

[fixxxer]

http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/routing.html
http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/security.html

Вопрос вкуса - хочется это всё в одном месте видеть или в контексте использования.

http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/view.html

Нормально.

http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/annotations.html

Хрень (выше писал почему).

 

[grigori]

проблема в том, что ошибки в аннотациях приходится дебажить по скомпилированному коду

и скорость, конечно - инициализация под 100мс