Рубин и утка: дизайн по контракту невозможен?
Подпись метода в Java:
public List<String> getFilesIn(List<File> directories)
похожий в рубине
def get_files_in(directories)
В случае Java система типов дает мне информацию о том, что метод ожидает и доставляет. В случае с Руби у меня естьнет понять, что я должен передать, или что я ожидаю получить.
В Java объект должен формально реализовывать интерфейс. В Ruby передаваемый объект должен реагировать на любые методы, вызываемые в методе, определенном здесь.
Это кажется весьма проблематичным:
Даже имея 100% точную и актуальную документацию, код Ruby должен по существу раскрыть свою реализацию, нарушая инкапсуляцию. Если не считать «чистоты ОО», это может показаться кошмаром обслуживания.Рубиновый код дает мненет разгадать, что возвращается; Мне пришлось бы по существу поэкспериментировать или прочитать код, чтобы выяснить, на какие методы ответил бы возвращаемый объект.Не хочу спорить о статической типизации против утиной, но хочу понять, как вы поддерживаете производственную систему, в которой у вас почти нет возможности проектировать по контракту.
ОбновитьНикто на самом деле не обращался к раскрытию внутренней реализации метода через документацию, которая требует этот подход. Поскольку интерфейсов нет, если я не ожидаю определенного типа, не нужно ли перечислять все методы, которые я могу вызвать, чтобы вызывающая сторона знала, что можно передать? Или это просто крайний случай, который на самом деле не подходит?