Рубин и утка: дизайн по контракту невозможен?

Подпись метода в Java:

public List<String> getFilesIn(List<File> directories)

похожий в рубине

def get_files_in(directories)

В случае Java система типов дает мне информацию о том, что метод ожидает и доставляет. В случае с Руби у меня естьнет понять, что я должен передать, или что я ожидаю получить.

В Java объект должен формально реализовывать интерфейс. В Ruby передаваемый объект должен реагировать на любые методы, вызываемые в методе, определенном здесь.

Это кажется весьма проблематичным:

Даже имея 100% точную и актуальную документацию, код Ruby должен по существу раскрыть свою реализацию, нарушая инкапсуляцию. Если не считать «чистоты ОО», это может показаться кошмаром обслуживания.Рубиновый код дает мненет разгадать, что возвращается; Мне пришлось бы по существу поэкспериментировать или прочитать код, чтобы выяснить, на какие методы ответил бы возвращаемый объект.

Не хочу спорить о статической типизации против утиной, но хочу понять, как вы поддерживаете производственную систему, в которой у вас почти нет возможности проектировать по контракту.

Обновить

Никто на самом деле не обращался к раскрытию внутренней реализации метода через документацию, которая требует этот подход. Поскольку интерфейсов нет, если я не ожидаю определенного типа, не нужно ли перечислять все методы, которые я могу вызвать, чтобы вызывающая сторона знала, что можно передать? Или это просто крайний случай, который на самом деле не подходит?

Ответы на вопрос(8)

Ваш ответ на вопрос