Java аннотации для шаблонов проектирования?

Это походит на неправильное употребление аннотаций мне. Несомненно, я видел, почему Вы могли бы хотеть отметить, какой шаблон разработки класс помогает реализовать, но просто использует Javadoc, и/или название класса кажется более соответствующим. Название шаблона, который Вы используете, не имеет фактического значения для самого кода..., шаблоны являются просто руководством для часто используемого способа решить проблему. Комментарий был бы достаточен, вместо того, чтобы создать новый файл для каждого шаблона, который Вы используете.

Это интересное решение, но мне интересно, что на самом деле проблема, которую вы решаете с этим? Или, другими словами, что вы получаете от использования чего-то подобного, что вы не получаете от правильного комментария в верхней части вашего класса о его использовании?

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

Минусы были бы, а именно:

1. еще одна вещь для программистов, чтобы думать, что никогда не бывает хорошо
2. , аннотированные шаблоны могут сбивать с толку - кто-то, вероятно, забыл задокументировать это, но, может быть, это не шаблон ...?
3. Вы действительно можете аннотировать все шаблоны ...? как насчет шаблонов, которые не привязаны к одному классу / методу, например, трехуровневый архитектурный шаблон или пул потоков, или даже MVC?

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

Во-первых, вы хотите документировать намерение (или намерение s ).

Итак, почему бы не использовать общую версию аннотации, например @UsePattern , которые используют @Documented , которое является аннотацией маркера ( хорошее руководство от IBM )? Что мне не нравится, так это то, что аннотация сохраняется во время выполнения, что является пустой тратой, если вы не хотите влиять на семантику программы.

Или Пользовательский тег Javadoc , который кажется более подходящим.

Некоторые информация о сравнении: Сравнение аннотаций и тегов Javadoc с красивым резюме из одного предложения:

<< В общем, если разметка предназначена для изменения или создания документации, она, вероятно, должна быть тег javadoc; в противном случае это должна быть аннотация. >

Я только что наткнулся на другую интересную для вас статью: Design Markers - Explicit Programming for the Rest of Us , в которой говорится об интерфейсах маркеров, таких как Сериализуемый .

По их словам:

... просто потому, что класс объявляет, что он "реализует Serializable »не означает, что он правильно реализовал контракт Serializable.

Поскольку Java не может точно сказать, был ли выполнен контракт, использование интерфейса маркера - это скорее явное обещание программиста, что он имеет.

Недооцененное преимущество интерфейсов маркеров состоит в том, что они также документируют намерение, что контракт должен быть выполнен ...

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

Даже если бы каждый класс «типизированного перечисления» имел комментарий, в котором отмечалось, что он следует этому шаблону, никакие уточнения (не говоря уже об учебной информации) не были бы добавлены, потому что либо приходилось копировать его повторно, или, что еще хуже, помещать его время от времени в произвольные места.

При создании комментариев JavaDoc, прикрепленных к каждому интерфейсу Design Marker, можно указать больше деталей, чем обычно, потому что комментарии не нужно повторять где-либо еще.

Они также упоминают некоторые недостатки, это хорошая пища для подумал!

Еще есть статья 2008 года по информатике: Реализация шаблона проектирования в Java и AspectJ , она была представлена ​​на OOPSLA 2008, что должно дать представление о ее качестве.

Хорошая цитата из него:

... простое существование классов, которые содержат исключительно код шаблона, служат записями о том, какие шаблоны используются. В случаях AspectJ мы наблюдаем два дополнительных улучшения. Во-первых, весь код, связанный с конкретным экземпляром шаблона, содержится в одном модуле (который определяет участников, назначает роли и т. Д.). Это означает, что все описание экземпляра шаблона локализовано и не «теряется» [21] или не «вырождается» [7] в системе. Во-вторых, с текущей поддержкой AspectJ IDE, всеми ссылками, рекомендованными методами и т. Д. являются гиперссылками, которые позволяют разработчику получить представление о назначении ролей и о том, где находятся интересующие концептуальные операции ...

Было бы лучше использовать аннотации для создания шаблона для Builder. Посмотрим правде в глаза, большинство из них довольно стандартны.

@Builder("buildMethodName")
Class Thing {
  String thingName;
  String thingDescr;
}

Типичное использование:

Thing thing =
      new Thing.Builder().setThingName("X").setThingDescr("x").buildMethodName();

Мне кажется, что аннотации используются не по назначению. Если нет намерения реализовать поведение с помощью этих аннотаций, я бы использовал принцип KISS: Обычный javadoc отлично подходит для документирования того, что должен делать/быть артефакт; пользовательские доклеты для расширения javadoc; и google для тех, кто хочет узнать, для чего нужен паттерн X или Y (или ссылка на него где-то в сети).

Существуют отличные, квази-официальные объяснения большинства паттернов. Зачем писать свое собственное? Есть ли дополнительная информация, которая важна для проекта? Использование аннотаций для обеспечения возможности перехода от javadoc одного класса к написанному на заказ javadoc паттерна похоже на историю о генеральном директоре, который собрал команду разработчиков для создания отчета, объединяющего итоги двух существующих квартальных отчетов - слишком сложно (и в то же время дешевле) складывать их итоги с помощью калькулятора 4 раза в год :-/

Во-первых, это очень хорошая идея, и я тусуюсь здесь только потому, что искал в Google библиотеку "аннотаций шаблонов проектирования". Хорошо, что я нашел это! Я проверю это и скоро дам ответ.

Всем скептикам: извините, очевидно, что большинство из вас не очень опытны в теме шаблонов дизайна. Например. Сообщение Мартина Харриса от 03 декабря 2009 в 21:56 ... Насколько я понимаю, вы хотели, чтобы ваш «пример» был простым. Но это не Строитель в смысле Паттерна проектирования.

То же самое я хочу сказать тем, кто вообще не видит пользы. Если отношения классов относительно их ролей в шаблонах дизайна аннотированы для класса, я могу использовать генератор для создания шаблонного кода. Я вижу все отношения поверх класса в исходном коде и могу использовать свои ярлыки IDE для перехода к соответствующим классам.

Если вы научились мыслить шаблонами и все шаблоны очевидны в исходном коде (через комментарии или аннотации), вы можете понять систему, состоящую из 200 классов, менее чем за час.

Относительно таких предложений, как использование @UsePattern () или @Builder ("buildMethodName") и т.д. ... тут мы должны спросить, как это сделать "сохранением"? В конце концов, эти строки подвержены опечаткам.

Одним из преимуществ правильных аннотаций является то, что вы можете аннотировать роли ... Большинство шаблонов проектирования состоят не из одного класса (например, синглтона), а из нескольких классов, работающих вместе! Например. если у вас есть строитель, результат (помеченный @Product) также может быть @Composite.Таким образом, построитель собирает части @Component (в отношении @Composite) и @Part (в отношении @Builder и @Product).

Возможно, лучшим аргументом в пользу таких аннотаций был бы java.lang.class, так что вы можете это выразить.

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

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

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

@AdapterPattern
public class EnumerationIteratorAdapter<T> implements Enumeration<T> {
  ...
}

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

Домашняя страница проекта находится на http://www.jpatterns.org , откуда вы также можете получить доступ к исходному дереву исходных текстов. Пожалуйста, свяжитесь со мной на сайте heinz по адресу javaspecialists dot eu, если вы хотите внести свой вклад в этот проект.

Хайнц (Информационный бюллетень специалистов по Java)