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

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

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

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

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

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

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

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

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

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

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

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

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

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

По их словам:

...just because a class declares that it "implements Serializable" doesn't mean that it has correctly implemented the Serializable contract.

Since Java can't really tell if the contract has been met, using the marker interface is more of an explicit pledge by the programmer that it has.

The overlooked benefit of marker interfaces is that they also document the intention that a contract should be met...

Why haven't design choices traditionally been recorded in source code? Mostly, because there has been no clear place to put them.

Even if each "typesafe enumeration" class had a comment noting that it followed that pattern, any elaboration (much less tutorial information) would not have been added because one either had to copy it repeatedly, or worse, place it sporadically in arbitrary spots.

When creating the JavaDoc comments attached to each Design Marker interface, one can put in more detail than is typical because the comments do not need to be repeated anywhere else.

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

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

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

... the mere existence of classes that exclusively contain pattern code serve as records of what patterns are being used. In the AspectJ cases, we observe two additional improvements. First, all code related to a particular pattern instance is contained in a single module (which defines participants, assigns roles, etc.). This means that the entire description of a pattern instance is localized and does not “get lost” [21] or “degenerate” [7] in the system. Secondly, with the current AspectJ IDE support, all references, advised methods etc. are hyperlinks that allow a developer an overview of the assignment of roles and where the conceptual operations of interest are...

Было бы лучше использовать аннотации для создания шаблона для 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)