Java аннотации для шаблонов проектирования? - PullRequest
16 голосов
/ 24 сентября 2008

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

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

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

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

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

Ответы [ 10 ]

7 голосов
/ 24 сентября 2008

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

6 голосов
/ 24 апреля 2009

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

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

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

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

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

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

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

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

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

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

4 голосов
/ 09 октября 2009

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

По их словам:

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

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

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

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

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

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

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

3 голосов
/ 04 декабря 2009

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

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

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

Thing thing =
      new Thing.Builder().setThingName("X").setThingDescr("x").buildMethodName();
3 голосов
/ 07 октября 2009

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

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

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

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

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

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

1 голос
/ 09 апреля 2010

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

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

1 голос
/ 13 октября 2009

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

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

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

0 голосов
/ 08 июля 2010

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

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

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

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

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

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

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

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

0 голосов
/ 18 августа 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...