是否有一个维护模式注释的项目？

解决方案

在我看来，这似乎是对注解的滥用。当然，我知道为什么我们可能要注意一个类在帮助实现哪种设计模式，但是仅使用Javadoc和/或者类名似乎更合适。我们所使用的模式的名称对代码本身并不重要。模式只是用于解决问题的常用方法的指南。注释就足够了，而不是为我们使用的每个模式创建一个新文件。

这是一个有趣的解决方案，但我一直在想我们要解决的问题到底是什么？或者换句话说，通过使用类似这样的东西，我们会从类的顶部对它的用法进行适当的评论而得不到什么呢？

我可以想到一些弊端，但除了这是一种很好的标准化代码编写方法之外，没有想到其他好处。

缺点将是：

• 程序员要考虑的另一件事，这从来都不是一件好事
• 未注释的模式可能会造成混淆-有人可能忘记了对其进行文档记录，但也许这不是一个模式..？
• 你能真正注释所有模式吗？不绑定到单个类/方法的模式，例如三层体系结构模式，线程池，甚至MVC，该怎么办？

如果我们还可以编写注释处理器来验证模式的某些属性，例如在实施模式时检查常见错误，则这将非常有用。编译器和程序员的文档。

首先，我们想要做的是记录一个或者多个意图。

因此，为什么不使用注释的通用版本，例如使用标记的注释的@Documented的@UsePattern之类的东西(来自IBM的好消息)呢？我不喜欢注释是在运行时保留的，除非我们不希望影响程序语义，否则这是一种浪费。

或者似乎更合适的自定义Javadoc标记。

有关比较的一些信息：用一个不错的句子摘要比较注释和Javadoc标签：

<<通常，如果标记旨在影响或者产生文档，则它可能应该是javadoc标记；否则，它应该是一个注释。 >>

关于注解或者javadoc标签的文档也有/曾经有过争论。

我偶然发现了另一篇对我们来说很有趣的文章："设计标记为我们其余人员进行的显式编程"，它讨论了标记接口，例如"可序列化"。

用他们的话说：

...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.

他们还提到了一些缺点，这是值得深思的！

另外，在OOPSLA 2008上还介绍了此2008年计算机科学论文：Java和AspectJ中的设计模式实现，该论文应说明其质量。

一个不错的报价：

... 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原则：Plain ol'javadoc可以很好地记录工件应该做什么/应该做什么；用于扩展javadoc的自定义doclet；对于那些想知道X或者Y模式是什么(或者在网络上某处的链接)的人，则使用google。

对于大多数模式，都有很好的准官方解释。为什么要自己写？是否有其他对项目至关重要的信息？使用注释来确保人们可以从一个班级的Javadoc导航到自定义编写的模式Javadoc，就像CEO的故事一样，他召集了一个开发团队来创建一个将两个现有季度报告的总和合并在一起的报告，这太困难了(而且价格便宜)，每年用计算器将两者的总和相加4次：-/

首先，这是一个非常好的主意，我只在这里闲逛，因为我在Google上搜索了"设计模式注释"库。好，我发现了这个！我将检查出来并尽快提供反馈。

对于所有怀疑论者：很抱歉，你们中的大多数人对设计模式都不是很有经验。例如。马丁·哈里斯(Martin Harris)从09年12月3日21:56开始的帖子...
我知道我们想简化"示例"。但这不是设计模式意义上的构建者。

对于那些根本看不到有用性的人，我也想说同样的话。如果将类与其在设计模式中的角色有关的关系注释给该类，则可以使用生成器来制作样板代码。我在源代码的类顶部看到了所有关系，并且可以使用我的IDE快捷方式导航到相关的类。

如果我们已经学会了思考模式，并且所有模式在源代码中都是显而易见的(通过注释或者注释)，那么我们可以在不到一个小时的时间内掌握一个由200个类组成的系统。

关于使用@UsePattern()或者@Builder(" buildMethodName")的建议
等...在这里，我们不得不问，如何使其成为" typesave"？毕竟那些字符串容易产生错别字。

正确注释的一个优点是我们可以注释角色...大多数设计模式不是由一个类(例如Singleton)组成，而是由多个类共同组成！例如。如果我们有构建器，则结果(用@Product注释)也可能是@Composite。因此，构建器将放在一起的部件将是@Component(关于@Composite)和@Part(关于@Builder和@Product)。

此类注释的最佳参数可能是java.lang.class，因此可以表达出来。

无论如何，只有一些想法...我等不及要回家玩弄你到目前为止拥有的东西了^^

我和迈克尔·汉格(Michael Hunger)已经启动了一个开放源代码项目，用于注释，以指定类所属的模式。我们在起步阶段是正确的，但很想听听意见。

我想采用KISS原则，以使人们尽可能容易地使用注释。例如，如果我们正在编写适配器，则可以简单地说：

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

当然，我们可以根据需要指定更多信息，例如角色，参与者和评论。我们希望这将使开发人员可以轻松地清晰地标记他们的课程。

该项目的主页位于http://www.jpatterns.org上，我们还可以从那里访问初始源代码树。如果我们想为该项目做出贡献，请通过javainspecialists dot eu在heinz与我联系。

Heinz(Java专家通讯)