У вас слишком много "динамических" в динамических языках?

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

Однако мои коллеги были "обвинены" в том, что мой код не является Groovy достаточно. А именно, я все еще объявляю типы для своих параметров и полей, как правило, использую наследование и полиморфизм вместо утиного ввода текста и т.д. Мне кажется, что в этих ситуациях это не только динамическая или статическая, но и динамическая или объектно-ориентированная парадигма вид дилеммы. В тех случаях я все же предпочитаю ОО. Я чувствую, что парадигма ОО имеет большую ценность в своей основной предпосылке, позволяя вам абстрагироваться и связывать ваши конструкции кода с конкретными концепциями реального мира.

Итак, вот конкретные вопросы, которые мне нужны для помощи:

Должен ли я объявлять типы для моих параметров, полей и т.д.?
Должен ли я объявлять блок кода как закрытие, когда будет выполняться простой метод?
Когда следует использовать утиную печать вместо полиморфной динамической отправки. Например, в Groovy я могу делать животное. $Action "() или def animal; animal.action(), а не животное animal = new Dog(); animal.action(). Я вижу проблему сперва в контексте принципа Open-Closed, но любые другие причины предпочитают полиморфизм стиля OO?
Когда я должен использовать интерфейсы в Groovy (если когда-либо)?

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

Ответ 1

0,1. Должен ли я объявлять типы для моих параметров, полей и т.д.?

Я склонен объявлять типы классов, которые используются как часть публичного API, то, что другие разработчики будут потреблять много, или где мне нужна дополнительная помощь автозаполнения от IntelliJ. В противном случае я 'def' вещи.

0,2. Должен ли я объявлять блок кода как закрытие, когда будет выполняться простой метод?

Я использую методы, если это не то, что я планирую передать в качестве переменной. Несмотря на то, что существует метод разыменования метода "foo. & bar", большинство разработчиков не знают об этом и путаются им, когда они сталкиваются с ним. Я также использую закрытие, когда это небольшой фрагмент кода, который ясен, чтобы оставаться в более крупном методе, а не вводить в него собственный метод для описательных целей.

0,3. Когда следует использовать утиную печать вместо полиморфной динамической отправки. Например, в groovy я могу делать животное. $Action "() или def animal; animal.action(), а не животное animal = new Dog(); animal.action(). Я вижу проблему сперва в контексте принципа Open-Closed, но любые другие причины предпочитают полиморфизм стиля OO?

Я использую только форму животного. $action "(), когда мне нужен этот уровень косвенности, потому что имя метода изменяется в зависимости от пути выполнения кода (чаще всего при тяжелом метапрограммировании). Я использую Animal animal = new Dog(); animal.action(), когда мне нужна помощь IDE с автозавершением, или этот уровень документации полезен для ясности кода (и не болит лишняя многословность, которая может быть очевидной или сдерживающей).

0,4. Когда следует использовать интерфейсы в groovy (если когда-либо)?

Я очень редко их использую. Я мог бы использовать их в основном как документацию ожидаемых полей для публичного вызова API или, возможно, как интерфейс маркера, чтобы помочь отличить один набор классов от другого с точки зрения метапрограммирования. Они менее полезны в groovy, чем в java.

Ответ 2

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

Мне не нравятся конструкции, которые оставляют вас гадать, что происходит...

Я работал в течение года в Ruby и мне совсем не нравилось. Я не говорю, что у него нет мест, где он превосходит, я просто говорю, что мне очень нравится держать вещи в чистоте и ясности и не чувствую, что у Руби это было как цель.

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

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

Ответ 3

Я думаю, что с помощью Groovy вы должны использовать простейший способ сделать что-то и отступить от функций groovier только тогда, когда ситуация требует этого. (Как при написании макросов или создании мультиметодов в Clojure, если вы слишком много добираетесь до этих инструментов, вы должны сами ставить под сомнение.) Ваш осторожный подход кажется мне прекрасным, возможно, ваши сотрудники немного опьянены их новыми идеями, нашел силу. (Это будет не первый раз.)

Хорошо, что с гибким языком, например Groovy, вы можете начать с осторожного подхода, как и вы, зная, что у вас есть более мощные альтернативы, чтобы отпасть, когда вы в них нуждаетесь. Вы знаете, "самое простое, что может сработать".

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

Ответ 4

Это сводится к тому, с чем люди чувствуют себя комфортно. Мне нравится использовать декодеры типов и вызовы методов, потому что мне удобно в Java. Код, который я пишу, должен поддерживаться людьми с большим опытом динамического программирования, поэтому я держу его близким к нормальному Java-коду, если нет веских оснований использовать расширенную функцию groovy. Похоже, что ваша группа должна создавать стандарты кодирования, которые пытаются объяснить, когда обычно должны использоваться конкретные функции groovy.

Ответ 5

Существует два доминирующих типа объектно-ориентированных языков.

Языки семейства Simula 67, такие как С++ и Java, поддерживают статически типизированные переменные, компиляторы и компоновщики, а также методы vtables.

Языки семейства Smalltalk, такие как Ruby, предпочитают динамически типизированные переменные, интерпретацию и передачу сообщений вместо таблиц указателей функций.

Оба являются объектно-ориентированными, но очень разные принимают понятие объектной ориентации.

Ответ 6

ДА

НЕТ

Вы понимаете, что нет реального ответа на этот вопрос?