设计模式的Java注释?

对我来说,这似乎是对注释的误用。当然,我可以理解为什么您可能需要注意类有助于实现的设计模式,但是仅仅使用Javadoc和/或类的名称似乎更合适。您正在使用的模式的名称对代码本身并不重要。。。模式只是解决问题的常用方法的指南。一个注释就足够了,而不是为您使用的每个模式创建一个新文件。

这是一个有趣的解决方案,但我一直想知道你用它解决的真正问题是什么?或者换言之,你从使用这样的东西中得到了什么?你在课堂上对它的使用做了适当的评论却没有得到什么?

我能想到一些缺点,但除了这是一种很好的标准化代码文档方式之外,我想不出还有什么好处。

缺点是:

1. 还有一件事程序员要考虑,那从来都不是好事
2. 未注释的模式可能会让人困惑——可能有人忘记记录它,但也许它不是一个模式。。?
3. 你真的能注释所有的模式吗。。?不绑定到单个类/方法的模式呢,例如三层架构模式、线程池,甚至MVC?

Michael Hunger和我已经开始了一个开源的注释项目,以指定类属于哪些模式。我们正处于起步阶段,但希望听到您的意见。

我想遵循KISS原则,以便使人们尽可能容易地使用注释。例如,如果您正在编写适配器,可以简单地说:

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

当然,如果需要,可以指定更多信息,例如角色、参与者和注释。我们希望这将使开发人员很容易清楚地标记他们的类。

项目主页正在运行 http://www.jpatterns.org 也可以从中访问初始源树。如果您想为项目做出贡献,请联系javaspecialists dot eu的heinz。

Heinz(Java专家通讯)

我无意中发现了另一篇你感兴趣的文章: Design Markers - Explicit Programming for the Rest of Us 关于标记接口,比如 Serializable .

用他们的话说:

……仅仅因为一个类声明它“实现了可序列化”,并不意味着它已经正确地实现了可序列化契约。

由于Java不能真正判断合同是否已经履行,所以使用marker接口更像是程序员的一个明确承诺。

标记接口被忽略的好处是,它们还记录了应该满足合同的意图。。。

为什么传统上设计选择没有记录在源代码中?主要是因为没有明确的地方放置它们。

即使每个“typesafe枚举”类都有一个注释,指出它遵循了该模式,也不会添加任何精化(更不用说教程信息),因为必须反复复制它,或者更糟的是,将它零星地放在任意位置。

在创建附加到每个设计标记接口的JavaDoc注释时,可以比通常的注释更加详细,因为这些注释不需要在其他任何地方重复。

他们也提到了一些缺点,这是一个很好的思考食物!

首先,你要做的是记录一个意图 s公司 ).

所以,为什么不使用注释的通用版本,比如 @使用模式 使用 @Documented 这是一个标记注释( nice tuorial from IBM )? 我不喜欢在运行时保留注释,这是一种浪费,除非您想影响程序语义。

或者 Custom Javadoc tag 这似乎更合适。

关于比较的一些信息: Comparing Annotations and Javadoc Tags 一句漂亮的总结:

<< 一般来说,如果标记是为了影响或生成文档,那么它应该是一个javadoc标记;否则,它应该是一个注释。 >gt;

关于 documentation as annotation or as javadoc tags .

更好的方法是使用注释为构建器实际构建样板。让我们面对现实吧,大多数都很标准。

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

典型用途:

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

另外还有一篇2008年的计算机科学论文: Design Pattern Implementation in Java and AspectJ ,它是在OOPSLA 2008上提出的,它应该表明它的质量。

很好的引用:

... 仅仅包含模式代码的类的存在只是作为使用模式的记录。在AspectJ案例中,我们观察到另外两个改进。首先,与特定模式实例相关的所有代码都包含在单个模块中(该模块定义参与者、分配角色等)。这意味着模式实例的整个描述是本地化的,不会在系统中丢失[21]或退化[7]。其次,在当前的AspectJ IDE支持下,所有引用、建议的方法等都是超链接,允许开发人员概述角色的分配以及感兴趣的概念操作在哪里。。。

对我来说好像是对注释的误用。除非有使用这些注释实现行为的意图,否则我将使用KISS原则:Plain ol'javadoc可以很好地记录工件应该做什么/应该做什么;自定义doclet可以扩展javadoc;google可以帮助那些想知道X或Y模式是什么的人(或者在web上的某个地方链接到它)

对于大多数模式都有很好的、准官方的解释。为什么要自己写?是否有其他对项目至关重要的信息?使用注释来确保可以从一个类的JavaDoc导航到一个定制的书写模式JavaDoc就像是CEO的故事,他召集了一个开发团队来创建一个报告,该报告结合了两个现有季度报告的总数,用计算器4次增加两个总数是太困难的(而且更便宜)。年份:-/

如果您还可以编写一个注释处理器来验证模式的某些属性(例如,在实现模式时检查常见错误),这将非常有用。编译器和程序员的文档。

首先,这是一个非常好的主意,我只是在这里闲逛,因为我在谷歌上搜索了一个“设计模式注释”库。很好我找到了这个!我会查出来并很快反馈。

对于所有的怀疑者:很抱歉,显然你们大多数人在设计模式这个话题上不是很有经验。E、 马丁·哈里斯从2009年12月3日21:56发来的邮件。。。 我知道你想保持你的“榜样”简单。但从设计模式的意义上说,这不是一个构建器。

同样,我想对那些根本看不到有用性的人说。如果类与它们在设计模式中的角色相关的关系被注释到类中,我可以使用生成器来创建样板代码。我在源代码中看到类顶部的所有关系,可以使用IDE快捷方式导航到相关类。

如果你学会了用模式思考,并且所有的模式在源代码中都是显而易见的(通过注释或注解),你可以在不到一个小时的时间里掌握一个由200个类组成的系统。

关于使用@UsePattern()或@Builder(“buildMethodName”)之类的建议 等等。。。我们要问的是,如何使它成为“typesave”?毕竟这些字符串容易出错。

正确注释的一个优点是可以注释角色。。。大多数设计模式不是由单个类(如Singleton)组成,而是由多个协同工作的类组成!E、 g.如果你有一个生成器,结果(用@Product注释)可能也是一个@Composite。因此,构建器正在组合的部分将是@Component(关于@Composite)和@Part(关于@builder和@Product)。

对于这样的注释,最好的参数可能是java.lang.class,因此您可以表达它。

不管怎样,只是一些想法。。。我迫不及待地想回家玩你现在有的东西^^