对于您的项目,您是否对Groovy有良好的体验?这个项目有多大?那语言有问题吗?你考虑过Jython,JRuby还是Clojure?
我喜欢
关闭
诽谤者
不需要通常冗余的声明MyType x = new MyType()
,这可以简化为简化def x = MyType()
.但是,在Groovy中打字是没有意义的(我不喜欢这样).
您可以使用控制台快速轻松地进行测试(尽管公平地说,您可以使用main(...)方法对Java类进行类似的操作).
我不喜欢
它是弱类型的.这会影响性能,并导致错误.做以下事情没有什么可以阻止你,甚至没有警告你:
def x = new MyComplexClass() // oops! accidentally made x equal to 1, that is, an integer x = 1 // Many lines later ... // big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation println "The result is ${x.myComplexOperation(a,b,c)}"
它会在运行时失败.
维护别人的代码很难.考虑到你可以为对象注入属性,你突然发现自己有变量,你不知道它们来自哪里,或者它们是什么类型.
使用更多单元测试可以"减轻"类型问题,但是,通过编写以下方法可以节省时间:
def add(a, b) { a + b}
可能因其他考虑而丢失:
您需要确定'a'和'b'是否是可接受的是您创建的String,整数或矩阵类,或其他内容.
如果你试试
def add(int a,int b){a + b}
Groovy将忽略参数的类型.所以任何人仍然可以将Strings或其他任何东西传递给方法"add".编译器不会抱怨.
所以现在你必须添加某种验证,如果你想确保参数是整数:
def (Integer a, Integer b) { assert a instanceof Integer assert b instanceof Integer a + b }
据我所知,静态语言编译器的目的是在编译时避免错误,而不是在运行时.
如果方法调用能够"抛出"错误,编译器不会警告您必须放置try-catch或向main方法添加"throws".如果你不知道某个方法可以抛出异常,你可以在不知不觉中编译一个没有编译错误的Groovy程序,直到它在运行时出现!
控制台不是那么好,因为它没有提供像Eclipse这样的IDE之类的建议.因此,您需要打开浏览器或书籍以查看课程的可用方法.还有另一个小陷阱:您不需要使用'def'来在控制台中定义变量,但是您需要在程序中使用它们.因此,如果从控制台复制并粘贴到IDE,但不要忘记def.
在我看来,Groovy数量有限,但不适合大型项目.这是因为许多可能的错误仅在运行时被检测到,因此需要更多的单元测试和断言,这部分地破坏了编写Groovy程序的速度.
默认情况下,Groovy中的属性是公共的,并且会自动创建gets和sets.您可以覆盖默认行为,但这只是您可以忘记的另一件事,并且阻碍了类的封装.例如:
?class Test { String a, b } class Test2 { def t = new Test() Test2 (String s) { t.a = s } ?}??????? } def t2=new Test2("I am public") println t2.t.a
我的团队最近使用Grails(以及暗示,Groovy)实现了一个小型的AtomPub服务.总的来说,这是一次很棒的体验.我们简要地将纯Java和JRuby视为替代品,而不是Jython或Clojure.该团队使用Groovy,因为它比JRuby更熟悉,但提供了比Java更多的灵活性.
以下是我们遇到的一些问题:
比我们大多数人习惯的工具支持更少(这有多大取决于您要求的个人开发人员)
令人毛骨悚然的堆栈跟踪(这可能比Groovy的更多是Grails的错误)
由于整个团队都在学习语言,因此难以达到一致,受欢迎的风格
Grails的文档不太理想(再次,不是Groovy的错); 文档正在迅速变化,所以现在情况可能有所改善
我目前正在使用Grails开展一个小型的探索性项目.我以前没有使用Groovy的经验,只有Java.
到目前为止,我对能够快速获取可用内容的速度印象深刻,而Groovy的功能,尤其是Gpath表达,在其中发挥了重要作用.我在Grails中遇到了一些错误,但在Groovy方面没有任何根本问题.
Groovy的主要缺点是(对我来说)调试比Java更不方便 - 堆栈跟踪因Groovy引擎盖下发生的反射魔法而膨胀,错误消息可能含糊不清 - 但这在很大程度上可能是由于我缺乏经验.