Может ли в динамических языках быть слишком много «динамического»?

https://stackoverflow.com/questions/1876810

18-09-2019
|

Вопрос

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

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

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

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

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

Решение

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

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

ДА

НЕТ

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow