Подтвердить что ты не робот

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

Есть ли проект, который поддерживает аннотации для шаблонов?

Например, когда я пишу построитель, я хочу отметить его @Builder.

Аннотирование таким образом сразу дает четкое представление о том, что реализует код. Кроме того, Javadoc аннотации @Builder может ссылаться на объяснения шаблона построителя. Кроме того, переход с Javadoc реализации строителя на @Builder Javadoc упрощается путем аннотации @Builder с помощью @Documented.

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

Обновление: в ответ на это обсуждение я создал Проект заметок рисунков. Вклады приветствуются! Вот @Builder

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

Я просто наткнулся на другую интересную для вас статью: Маркеры проектирования - Явное программирование для остальных пользователей, в котором рассказывается о интерфейсах маркеров, например Serializable.

По их словам:

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

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

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

 

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

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

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

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

Ответ 5

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

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

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

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

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

Есть и были некоторые обсуждения в документации как аннотации или как теги javadoc.

Ответ 6

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

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

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

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

Ответ 7

Кроме того, в этом документе "Компьютерные науки" за 2008 год: Реализация шаблона проектирования в Java и AspectJ, он был представлен на OOPSLA 2008, который должен дать указание на его качество.

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Для всех скептиков: извините, очевидно, что большинство из вас не очень опытные в теме дизайнерских паттеров. Например. Мартин Харрис сообщение с 3 декабря 2009 в 21:56... Я понимаю, что вы хотели сохранить свой "пример" простым. Но это не Builder в смысле дизайна.

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

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

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

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

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

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