Groovy: замыкания или методы - PullRequest
       11

Groovy: замыкания или методы

36 голосов
/ 01 декабря 2009

Я привык использовать Closures везде, где только можно, вместо обычных методов, даже когда мне не нужен доступ к свободным переменным. Итак, я буду использовать это:

def addNumbers = { left, right -> left + right }

.. вместо этого:

def addNumbers (left,right) { left + right }

Это плохая практика? Я предпочитаю дополнительную мощность, которую я получаю при использовании замыканий, вместо методов, и я предпочитаю синтаксис.

Спасибо!

Ответы [ 2 ]

45 голосов
/ 01 декабря 2009

Я использую замыкания только там, где они мне нужны, т.е. я использую методы по умолчанию. Я делаю это, потому что

  • Методы проще, чем у замыканий. У замыканий есть делегат, владелец, сохраняющий доступ к переменным, которые были в их локальной области при создании (то, что вы называете "свободными переменными"). По умолчанию вызовы методов внутри замыкания разрешаются следующим образом:

    1. Само закрытие
    2. Закрытие владельца
    3. Делегат закрытия

Но этот порядок может быть изменен во время выполнения, и делегат замыкания также может быть изменен на любой объект.

Все эти факторы в совокупности могут сделать некоторый код, который использует замыкания, очень сложным для выполнения, поэтому, если вам не нужна эта сложность, я предпочитаю устранить ее, используя вместо этого метод

  • Файл .class генерируется для каждого замыкания, определенного в Groovy. У меня есть ровно ноль доказательств в поддержку утверждения, что обычный метод более эффективен, чем замыкание, но у меня есть подозрения. По крайней мере, многие классы могут привести к тому, что вы исчерпаете пространство памяти PermGen - это часто случалось со мной, пока я не увеличил пространство PermGen примерно до 200 МБ

Я понятия не имею, является ли практика, которую я защищаю (использовать методы по умолчанию и закрытие только тогда, когда они вам нужны), широко считается "лучшей практикой", поэтому мне любопытно услышать, что думают другие.

6 голосов
/ 29 декабря 2009

Хотя все, что говорит @Дон, верно, я не знаю, что все это так важно. Вы можете переопределить делегат замыкания, который может изменить выполнение, но если вы не передаете замыкание (что вы не можете сделать с методом в любом случае), вам не нужно беспокоиться о том, что произойдет. Игра с делегатом - это особенность, а не обязанность.

Что касается возможного снижения производительности из файлов дополнительного класса, почему вы используете Groovy, если вас беспокоит производительность?

Мое мнение таково, что это не имеет значения. Если в вашей команде много людей, которые являются старыми разработчиками Java, им, вероятно, не понравится, когда вы используете замыкания, когда метод подойдет. С другой стороны, если кто-то свободно говорит на Groovy, он будет раздражен, если вы все загромождаете методами, когда замыкание имеет больше смысла.

tl; dr - жестких и быстрых правил не существует, вместо этого вы должны проявить здравый смысл, ориентируясь на читабельность кода.

...