Double a = b - c * d; //natural way
如
BigDecimal a = b.subtract(c.multiply(d))//BigDecimal way
不仅丑陋,而且是我和业务分析师之间的错误和沟通问题的根源.他们完全可以用双打来读取代码,但现在他们不能.
当然,一个完美的解决方案将是java对操作符重载的支持,但由于不会发生这种情况,我正在寻找一个eclipse插件,甚至是一个外部工具,可以实现从“自然的方式”到“bigdecimal”的自动转换.
我不是试图预处理源代码或动态翻译或任何复杂的东西,我只是想要一些我可以输入文本和获取文本,并保持“自然的方式”作为一个注释在源代码.
P.S .:我找到了this incredible smart hack,但是我不想开始进行字节码操作.也许我可以使用它来创建一个Natural2BigDecimal翻译器,但如果有人已经做了这样一个工具,我不想重新发明.
我不想切换到Scala / Groovy / JavaScript,我也不能,公司规则禁止任何东西,但服务器端代码中的java.
解决方法
解决问题的一半是认识到它的问题.您完全需要预处理您的BigDecimal表达式来产生合法的Java.
你只有两个基本的选择：
>独立的“域特定语言”和DSL编译器,接受“标准”表达式,并将它们直接转换为Java代码. (这是一种预处理器).这会让您遇到保留所有表达式片段的问题,并以某种方式知道将其放在Java代码中的位置.
>读取Java源文本的工具,查找这些表达式,并将其转换为文本中的BigDecimal.我会提出一些让你在实际代码之外编写表达式并插入翻译的东西.
(也许(从另一个答案中偷走)：
// BigDecimal a = b - c * d; BigDecimal a = b.subtract( c.multiply( d ) );
具有意义“将注释中的大十进制表达式编译为其Java等效项,并将该语句替换为该翻译.
要实现第二个想法,您需要一个program transformation system,它可以应用源到源重写规则来转换(生成转换的特殊情况)代码.这只是一个预处理器,可以根据您的需要进行自定义.
我们DMS Software Reengineering Toolkit与Java Front End 可以做到这一点.你需要一个完整的Java解析器来做这个转换部分;您将需要名称和类型解析,以便您可以解析/检查提出的表达式以确定.
虽然我同意现有的Java符号是丑陋的,你的建议会让它更漂亮,但我个人的看法是不值得的.你最终依赖于一个复杂的工具(是的,DMS是复杂的：操纵代码并不容易),这是一个相当微不足道的收益.
如果您和您的团队撰写了数千种这些公式,或者这些公式的作者是Java天真的,这可能是有道理的.在这种情况下,我会进一步,只是坚持你写你需要的标准表达格式.您可以自定义Java前端以检测操作数类型为十进制类型,并为您重写.然后,您只需在每个Java编译步骤之前运行此预处理程序.
