技术开发 频道

Amber项目中,关于Java“数据类”的建议

  【IT168 资讯】 在Amber项目中,有一份关于Java“数据类”的新建议草案,笔者总结了以下几个要点:

  1. 设计意图:明确无误地表达一个类作为 “DTO”的设计意图;

  2. 样板:让编译器负责像equals()和hashCode()这样的典型DTO一样来操作;

  3. Switch语句:简要介绍了在DTO周围启用语义特征,能够将它们用作switch语句的目标;

  该草案还涉及到一些具体的细节,如访问者不必遵循JavaBeans约定、选择可变性和迁移/兼容性等问题。

  笔者通过分析以下几点,为大家解释不看好这个提案的原因。

  设计意图

  这是一个很有价值的目标:读者将立即明白数据类的设计意图,不必通过典型的getter、setter、equals、hashCode和toString来实现遍历,以确保该类只有一个数据类。

  退一步问:在项目中定义了多少DTO类型,这种新的语言结构是否会大大简化代码?如果这两个问题的答案都是“很多”,那么就有了一个更深层次的问题,这个新构造不能解决的问题:可能没有以面向对象的方式来思考问题。所定义的许多类型只是数据的一部分,而且很可能是用命令式的方式编程。这是笔者的论点的根结所在。DTO是一个反模式,但纯粹的OOP是不实际的,因此,没有必要去纠结。

  是的,DTO有时是不可避免的,尤其是在与远程API(例如JAX-WS)接口时。但是,有几点:

  * 这些都应该存在于代码的外围;

  * 它们应该被域模型封装,其中有类似于equals()和hashCode()的重要方法;

  DTO如果存在的话,应该只存在于项目的边缘,而不是整个设计理念的主干。理想情况下,它们应该只有在像wsimport这样的框架/工具自动生成时才存在。

  样板

  如果接受了前面的论点,那么getter / setter“样板”就不存在争论:工具只会在需要的地方自动创建。关于需要注意的其他Object方法:equals()和hashCode(),笔者有一些自己的想法:

  *它们应该被从Object中取出,并且进入它们自己的接口;

  *并不是所有的API都需要所有的DTO来实现equals(),更不必说hashCode();

  Switch语句

  可能是由于性能或者其他问题,没使用Object#equals打开任何对象。一个SO用户表达了自己观点:“...技术障碍不应该推动语言设计。如果没有办法将它编译成高效的代码,它仍然可能被编译成if ... else ...子句的等价形式,仍然有源代码简洁的优点”。

0
相关文章