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

Question

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

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

Итак, вот конкретные вопросы, мне нужна помощь с:

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

ДА

-

NO

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

Answer 6

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

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

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

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