Groovy и динамические методы: нужно заводное просвещение ветеранов - PullRequest
Новая
       31

Groovy и динамические методы: нужно заводное просвещение ветеранов

0 голосов
/ 13 декабря 2011

Во-первых, я должен сказать, что мне действительно нравится Groovy и все то хорошее, что он приносит в мир Java-разработки. Но поскольку я использую его не только для небольших сценариев, у меня есть некоторые проблемы.

На этой странице справки Groovy о динамической и статической типизации есть это заявление об отсутствии ошибки / предупреждения компиляции, когда в вашем коде есть опечатка, поскольку это может быть вызов метода, добавленного позже. во время выполнения:

Может быть страшно покончить со всей вашей статической типизацией и проверка времени компиляции сначала. Но многие ветераны Groovy будут свидетельствовать что он делает код чище, его проще реорганизовать, и, что еще лучше, динамический.

Я вполне согласен с «более динамичной» частью, но не с более чистой и простой в рефакторинге:
Что касается двух других утверждений, я не уверен: с моей точки зрения начинающего Groovy, это приводит к меньшему количеству кода, но к более трудному чтению позже и к большим трудностям в обслуживании (больше не могу полагаться на IDE, чтобы найти, кто объявляет динамический метод и кто его использует).

Чтобы уточнить, я считаю, что чтение отличного кода очень приятно, мне нравится сбор и закрытие (краткий и выразительный способ решения сложной проблемы). Но у меня много проблем в таких ситуациях:

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

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

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

Я был бы очень рад узнать от заводного ветерана, как они могут засвидетельствовать эти преимущества.

Ответы [ 3 ]

2 голосов
/ 13 декабря 2011

Это действительно приводит к различным классам ошибок и процессов.Это также делает написание тестов более быстрым и естественным, помогая устранить проблемы с ошибками.

Может быть проблематично определить, где определяется и используется поведение.Это не лучший способ, хотя со временем IDE становятся лучше.

Ваш код не должен быть более сложным для чтения - основной код должен быть проще читать.Динамическое поведение должно исчезнуть в приложении и соответствующим образом документироваться для разработчиков, которым необходимо понимать функциональность на этих уровнях.

Магия действительно делает обнаружение более трудным.Это означает, что другие средства документирования, в частности, удобочитаемые тесты (например, easyb, spock и т. Д.) И проза, становятся гораздо более важными.

1 голос
/ 14 апреля 2012

Это несколько устарело, но я хотел бы поделиться своим опытом, если кто-то придет в поисках мыслей на эту тему:

В настоящее время мы используем eclipse 3.7 и groovy-eclipse 2.7 в небольшой команде (3 разработчика), и, поскольку у нас нет сценариев тестирования, в основном в нашей разработке на Groovy мы используем явное использование типов.

Например, при использовании методов классов обслуживания: 

void validate(Product product) {
  // groovy stuff
}

Box pack(List<Product> products) {
  def box = new Box()
  box.value = products.inject(0) { total, item ->
    // some BigDecimal calculations =)
  }
  box
}

Обычно мы заполняем тип, который позволяет автозаполнению eclipse и, что наиболее важно, позволяет нам реорганизовывать код, находить примеры использования и т. Д.

Это блокирует нас от использования метапрограммирования, за исключением категорий, которые, как я обнаружил, поддерживаются и обнаруживаются groovy-eclipse.

Тем не менее Groovy довольно хорош, и большая часть нашей бизнес-логики представлена ​​в отличном коде.

У нас было две проблемы в рабочем коде при использовании groovy, и оба случая были из-за плохого ручного тестирования.

У нас также есть много возможностей для создания и анализа XML, и мы проверяем его перед отправкой на веб-службы и тому подобное.

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

Я думаю, что groovy 2.0 (конечно, с groovy-eclipse) и его @TypeChecked отлично подойдет для тех из нас, кто использует groovy как java ++.

0 голосов
/ 14 декабря 2011

Для меня существует 2 вида рефакторинга:

  1. Рефакторинг на основе IDE (извлечение в метод, метод переименования, введение переменной и т. Д.).
  2. Ручной рефакторинг. (перемещение метода в другой класс, изменение возвращаемого значения метода)

Для рефакторинга на основе IDE я не нашел IDE, которая бы работала с Groovy так же хорошо, как с Java. Например, в eclipse, когда вы извлекаете метод, он ищет дублирующиеся экземпляры для рефакторинга, чтобы вызвать метод вместо дублированного кода. Для Groovy этого не происходит.

Рефакторинг вручную - вот где я считаю, что вы могли бы увидеть, что рефакторинг стал проще. Хотя без тестов я бы согласился, что это, вероятно, сложнее.

Утверждение в чистом коде 100% точности. Я бы рискнул предположить, что от хорошего Java к хорошему Groovy-коду - это как минимум сокращение строк кода на 3: 1. Будучи новичком в Groovy, я бы старался выучить хотя бы один новый способ делать что-то каждый день. Что-то, что очень помогло мне улучшить мой Groovy, было просто читать API. Мне кажется, что Collection, String и List, вероятно, являются наиболее функциональными, и я больше всего использовал их для того, чтобы сделать мой код на Groovy действительно Groovy.

http://groovy.codehaus.org/groovy-jdk/java/util/Collection.html

http://groovy.codehaus.org/groovy-jdk/java/lang/String.html

http://groovy.codehaus.org/groovy-jdk/java/util/List.html

Поскольку вы редактировали вопрос, я отредактирую свой ответ:)

Одна вещь, которую вы можете сделать, это рассказать intellij о динамических методах ваших объектов: Что делает «добавить динамический метод» в Groovy / IntelliJ? . Это может немного помочь.

Еще одна хитрость, которую я использую, - это печатать мои объекты при первоначальном кодировании и снимать печать, когда я закончу. Например, я никогда не могу вспомнить, если это .substring (..) или .subString (..) в строке. Поэтому, если вы наберете свой объект, вы получите немного лучшее завершение кода.

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

...