你对Groovy有什么看法?

Ber*_*own 12 groovy clojure

对于您的项目,您是否对Groovy有良好的体验?这个项目有多大?那语言有问题吗?你考虑过Jython,JRuby还是Clojure?

lui*_*ado 10

我喜欢

  1. 关闭
  2. 诽谤者
  3. 不需要通常冗余的声明MyType x = new MyType(),这可以简化为简化def x = MyType().但是,在Groovy中打字是没有意义的(我不喜欢这样).
  4. 您可以使用控制台快速轻松地进行测试(尽管公平地说,您可以使用main(...)方法对Java类进行类似的操作).

我不喜欢

  1. 它是弱类型的.这会影响性能,并导致错误.做以下事情没有什么可以阻止你,甚至没有警告你:

    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)}"
    
    Run Code Online (Sandbox Code Playgroud)

它会在运行时失败.

  1. 维护别人的代码很难.考虑到你可以为对象注入属性,你突然发现自己有变量,你不知道它们来自哪里,或者它们是什么类型.

  2. 使用更多单元测试可以"减轻"类型问题,但是,通过编写以下方法可以节省时间:

    def add(a, b) { a + b}
    
    Run Code Online (Sandbox Code Playgroud)

    可能因其他考虑而丢失:

    • 您需要确定'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
}
Run Code Online (Sandbox Code Playgroud)

据我所知,静态语言编译器的目的是在编译时避免错误,而不是在运行时.

  1. 如果方法调用能够"抛出"错误,编译器不会警告您必须放置try-catch或向main方法添加"throws".如果你不知道某个方法可以抛出异常,你可以在不知不觉中编译一个没有编译错误的Groovy程序,直到它在运行时出现!

  2. 控制台不是那么好,因为它没有提供像Eclipse这样的IDE之类的建议.因此,您需要打开浏览器或书籍以查看课程的可用方法.还有另一个小陷阱:您不需要使用'def'来在控制台中定义变量,但是您需要在程序中使用它们.因此,如果从控制台复制并粘贴到IDE,但不要忘记def.

  3. 在我看来,Groovy数量有限,但不适合大型项目.这是因为许多可能的错误仅在运行时被检测到,因此需要更多的单元测试和断言,这部分地破坏了编写Groovy程序的速度.

  4. 默认情况下,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
    
    Run Code Online (Sandbox Code Playgroud)


Han*_*Gay 7

我的团队最近使用Grails(以及暗示,Groovy)实现了一个小型的AtomPub服务.总的来说,这是一次很棒的体验.我们简要地将纯Java和JRuby视为替代品,而不是Jython或Clojure.该团队使用Groovy,因为它比JRuby更熟悉,但提供了比Java更多的灵活性.

以下是我们遇到的一些问题:

  • 比我们大多数人习惯的工具支持更少(这有多大取决于您要求的个人开发人员)
  • 令人毛骨悚然的堆栈跟踪(这可能比Groovy的更多是Grails的错误)
  • 由于整个团队都在学习语言,因此难以达到一致,受欢迎的风格
  • Grails的文档不太理想(再次,不是Groovy的错); 文档正在迅速变化,所以现在情况可能有所改善


Mic*_*rdt 6

我目前正在使用Grails开展一个小型的探索性项目.我以前没有使用Groovy的经验,只有Java.

到目前为止,我对能够快速获取可用内容的速度印象深刻,而Groovy的功能,尤其是Gpath表达,在其中发挥了重要作用.我在Grails中遇到了一些错误,但在Groovy方面没有任何根本问题.

Groovy的主要缺点是(对我来说)调试比Java更不方便 - 堆栈跟踪因Groovy引擎盖下发生的反射魔法而膨胀,错误消息可能含糊不清 - 但这在很大程度上可能是由于我缺乏经验.