企业网站开发用什么好,网络货运公司排名,wordpress美化登录界面,辽宁网站建设熊掌号十年前的2004年 #xff0c; Java 1.5开始提供注释。 很难想象没有此功能的代码。 实际上#xff0c;首先引入了注释#xff0c;以减轻开发人员编写繁琐的样板代码的痛苦#xff0c;并使代码更具可读性。 考虑一下J2EE 1.4#xff08;没有可用的注释#xff09;和Java EE… 十年前的2004年 Java 1.5开始提供注释。 很难想象没有此功能的代码。 实际上首先引入了注释以减轻开发人员编写繁琐的样板代码的痛苦并使代码更具可读性。 考虑一下J2EE 1.4没有可用的注释和Java EE5。注释的采用通过消除所有配置XML大大简化了Java EE应用程序的开发。 即使在今天更多的注释仍被添加到最新版本的Java EE中。 这样做的目的是减轻开发人员的负担并提高生产率。 其他技术和框架也广泛使用它们。 到处都有注释 让我们看一个有关注释如何简化代码的示例摘自我有关JPA实体图的文章 电影.java Entity
Table(name MOVIE_ENTITY_GRAPH)
NamedQueries({NamedQuery(name Movie.findAll, query SELECT m FROM Movie m)
})
NamedEntityGraphs({NamedEntityGraph(name movieWithActors,attributeNodes {NamedAttributeNode(movieActors)}),NamedEntityGraph(name movieWithActorsAndAwards,attributeNodes {NamedAttributeNode(value movieActors, subgraph movieActorsGraph)},subgraphs {NamedSubgraph(name movieActorsGraph,attributeNodes {NamedAttributeNode(movieActorAwards)})})
})
public class Movie implements Serializable {Idprivate Integer id;NotNullSize(max 50)private String name;OneToManyJoinColumn(name ID)private SetMovieActor movieActors;OneToMany(fetch FetchType.EAGER)JoinColumn(name ID)private SetMovieDirector movieDirectors;OneToManyJoinColumn(name ID)private SetMovieAward movieAwards;
} 等一下 简化吗 真 注释不应该使我的代码更具可读性吗 此示例具有比实际代码更多的注释。 公平地说我不包括获取器和设置器。 同样某些带注释的代码可以更好地压缩但这会使代码更难阅读。 当然这是一个极端的情况。 无论如何我很高兴因为我获得了“年度注释狂”称号 。 谢谢卢卡斯 我们非常依赖注释以至于最终滥用它们。 有趣的是在某些情况下批注引起了他们打算解决的相同问题。 如果 让我们像这样重写前面的示例 电影.java MovieEntity
FindAll
LoadWithActors
LoadWithActorsAndAwards
public class Movie implements Serializable {Idprivate Integer id;Nameprivate String name;MovieActorsprivate SetMovieActor movieActors;MovieDirectorsprivate SetMovieDirector movieDirectors;MovieAwardsprivate SetMovieAward movieAwards;
} 它肯定看起来更具可读性。 但是这些注释不存在。 他们来自哪里 LoadWithActors LoadWithActors.java NamedEntityGraph(name movieWithActors,attributeNodes {NamedAttributeNode(movieActors)}
)
public interface LoadWithActors {}LoadWithActorsAndAwards LoadWithActorsAndAwards.java NamedEntityGraph(name movieWithActorsAndAwards,attributeNodes {NamedAttributeNode(value movieActors, subgraph movieActorsGraph)},subgraphs {NamedSubgraph(name movieActorsGraph,attributeNodes {NamedAttributeNode(movieActorAwards)})}
)
public interface LoadWithActorsAndAwards {} 其余的依次类推。 你有感觉。 这个想法是将注释元数据提取并分组到您自己的自定义注释中。 然后您的注释可以用于表示代码中所有带注释的数据从而更易于理解。 就像Java 8 Lambdas一样读起来就像问题声明一样。 只是另一个例子 WoWBusinessBean.java Named
Stateless
TransactionAttribute(TransactionAttributeType.SUPPORTS)
ApplicationPath(/resources)
Path(wowauctions)
Consumes(MediaType.APPLICATION_JSON)
Produces(MediaType.APPLICATION_JSON)
public class WoWBusinessBean extends Application implements WoWBusiness {} 改写 WoWBusinessBean.java RestStatelessBean(wowauctions)
public class WoWBusinessBean extends Application implements WoWBusiness {}RestStatelessBean RestStatelessBean Named
Stateless
TransactionAttribute(TransactionAttributeType.SUPPORTS)
ApplicationPath(/resources)
Path(#{path})
Consumes(MediaType.APPLICATION_JSON)
Produces(MediaType.APPLICATION_JSON)
public interface RestStatelessBean {String value() default #{path};
} 通常我只编写一次这些注释来定义POJO的行为而不再关注它们。 如果我可以为所有无状态休息服务重用一个注释那将有多酷 另一个不错的效果是注释配置元数据没有直接绑定在代码中。 相反它被抽象为另一个注释。 在这种情况下有可能在编译/运行时中覆盖或替换这些值。 元注释 我最初是由David Blevins听说过这个概念的。 他在“ 元注释”中写了一篇关于这些想法的很好的文章甚至写了一个可能的实现 。 为注释继承抽象和封装提供简单的Java SE支持会很方便。 这是所有现有技术处理注释方式的重大转变。 只有每个人都开始支持这种行为才有意义。 有人可能会问我们真的需要此功能吗 让我们尝试权衡一些利弊 优点 简化代码。 注释重用。 注释配置不直接与代码绑定。 值可以被覆盖。 缺点 另一层抽象。 自由地创建自定义注释可以掩盖真实行为。 可能会遇到某种多重继承陷阱。 结论 在可预见的将来这种元注释不太可能在Java SE中提供。 在Java 9中大多数焦点都放在Jigsaw中。 除了值类型和泛型专业化之外关于Java 10的信息很少。 实际上对于纯Java SE所有这些注释问题都不是真正的问题。 源文件中存在的批注数量正成为有关可读性和可维护性的问题。 对于Java EE和其他类似技术尤其如此。 考虑一下HTML和CSS。 如果您正在开发HTML页面而只需要几个CSS样式则通常将它们内联到元素中或直接将它们包括在页面中。 如果开始使用太多样式则可以将它们提取到外部CSS文件中然后应用样式。 我确实认为必须通过采用元注释或其他方式来完成某些工作。 你还有其他建议吗 请分享 资源资源 不要忘记查看David Blevins关于Meta Annotations的帖子。 他的解释比我更好包括技术细节。 也是带有元注释的JavaOne EJB演示文稿由David Blevins讨论了这些想法。 还有什么比听大卫·布莱文斯本人更好的呢 Java EE 7无限可扩展性遇到无限重用 。 翻译自: https://www.javacodegeeks.com/2014/12/annotations-annotations-everywhere.html
