Каковы некоторые преимущества ввода утки по сравнению со статическим контролем типов?

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

Набор @Chris

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

Жаль, но я должен был сделать это...

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

Groovy кажется мне таким же образом. Конечно, вы можете написать очень краткий код и определенно есть какой-то хороший сахар в том, как мы добились работы со свойствами, коллекциями и т. Д. В какой-то момент ваша царапающая голова задавалась вопросом, почему проект стал 80% тестированием и 20%. Урок вот что «меньше» не делает «более читаемый» код. Извините, люди, его простая логика - тем больше вы должны интуитивно знать, чем более сложный процесс понимания того, что кодекс становится. Поэтому GUI отступил к чрезмерно сланскому искочеству в течение многих лет - наверняка выглядит красиво, но WTH идет не всегда очевидно.

Люди в этом проекте, казалось, имели проблемы «прибиты» извлеченные уроки, но когда у вас есть методы, возвращающие один элемент типа T, массив T, ошибочно или нулевой ... это становится довольно очевидной Отказ

Одна вещь, работающая с Groovy сделала для меня, однако - потрясающие платежные часы Woot!

Вот один сценарий, в котором утка сокращает работу.

Вот очень простой класс

class BookFinder {
    def searchEngine

    def findBookByTitle(String title) {
         return searchEngine.find( [ "Title" : title ] ) 
    }
}

Теперь о модульном тесте:

void bookFinderTest() {
    // with Expando we can 'fake' any object at runtime.
    // alternatively you could write a MockSearchEngine class.
    def mockSearchEngine = new Expando()
    mockSearchEngine.find = {
        return new Book("Heart of Darkness","Joseph Conrad")
    }

    def bf = new BookFinder()
    bf.searchEngine = mockSearchEngine
    def book = bf.findBookByTitle("Heart of Darkness")
    assert(book.author == "Joseph Conrad"
}

Мы смогли заменить SearchEngine Expando из-за отсутствия проверки статического типа. При проверке статического типа нам пришлось бы убедиться, что SearchEngine был интерфейсом или, по крайней мере, абстрактным классом, и создать его полную фиктивную реализацию. Это трудоемко, или вы можете использовать сложный одноцелевой фреймворк для фиксации. Но утиная печать универсальна и помогла нам.

Из-за утиной печати наш модульный тест может предоставить любой старый объект вместо зависимости, при условии, что он реализует вызываемые методы.

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

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

Мое мнение:

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

Держитесь подальше от всех языков, которые не являются статически типизированными, все остальное - просто мазохизм.