Ruby and duck typing: дизайн по контракту невозможен?

Все сводится к тому, что get_files_in - плохая репутация в Ruby - позвольте мне объяснить.

В java / C # / C ++ и особенно в цели C аргументы функции являются частью имени. В Ruby это не так.
Замечательный термин для этого - перегрузка метода, и он применяется компилятором.

Думая об этом в этих терминах, вы просто определяете метод с именем get_files_in и на самом деле не говорите, куда он должен загружать файлы. Аргументы не являются частью имени, поэтому вы не можете положитесь на них, чтобы идентифицировать его.
Должен ли он получать файлы в каталоге? вождение? сетевой ресурс? Это дает ему возможность работать во всех вышеперечисленных ситуациях.

Если вы хотите ограничить его каталогом, то, чтобы учесть эту информацию, вы должны вызвать метод get_files_in_directory. В качестве альтернативы вы можете сделать его методом класса Directory, который Ruby уже делает за вас.

Что касается типа возврата, из get_files подразумевается, что вы возвращаете массив файлов. Вам не нужно беспокоиться о том, что это List<File> или ArrayList<File> или так далее, потому что все просто используют массивы (и если они написали собственный, они напишут его для наследования от встроенного массива) .

Если вы хотите получить только один файл, вы бы назвали его get_file, get_first_file или так далее. Если вы делаете что-то более сложное, например, возвращаете FileWrapper объектов, а не просто строки, то есть действительно хорошее решение:

# returns a list of FileWrapper objects
def get_files_in_directory( dir )
end

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

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

Я бы сказал, что, хотя метод Java дает вам больше информации, он не дает вам достаточно информации для удобного программирования.
Например, это Список Строки просто имена файлов или полные пути?

Учитывая это, ваш аргумент о том, что Ruby не дает вам достаточно информации, применим и к Java.
Вы по-прежнему полагаетесь на чтение документации, просмотр исходного кода или вызов метода и просмотр его вывода (и достойного тестирования конечно).

Хотя я люблю статическую типизацию, когда пишу код Java, нет причин, по которым вы не можете настаивать на продуманных предварительных условиях в коде Ruby (или любом другом коде в этом отношении). Когда мне действительно нужно настаивать на предварительных условиях для параметров метода (в Ruby), я рад написать условие, которое могло бы вызвать исключение времени выполнения, чтобы предупредить об ошибках программиста. Я даже создаю себе подобие статической типизации, написав:

def get_files_in(directories)
   unless File.directory? directories
      raise ArgumentError, "directories should be a file directory, you bozo :)"
   end
   # rest of my block
end

Мне не кажется, что язык мешает вам заниматься проектированием по контракту. Скорее мне кажется, что это дело разработчиков.

(Кстати, «бозо» относится к вашему искреннему :)

Проверка метода с помощью утиного ввода:

i = {}
=> {}
i.methods.sort
=> ["==", "===", "=~", "[]", "[]=", "__id__", "__send__", "all?", "any?", "class", "clear", "clone", "collect", "default", "default=", "default_proc", "delete", "delete_if", "detect", "display", "dup", "each", "each_key", "each_pair", "each_value", "each_with_index", "empty?", "entries", "eql?", "equal?", "extend", "fetch", "find", "find_all", "freeze", "frozen?", "gem", "grep", "has_key?", "has_value?", "hash", "id", "include?", "index", "indexes", "indices", "inject", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "invert", "is_a?", "key?", "keys", "kind_of?", "length", "map", "max", "member?", "merge", "merge!", "method", "methods", "min", "nil?", "object_id", "partition", "private_methods", "protected_methods", "public_methods", "rehash", "reject", "reject!", "replace", "require", "respond_to?", "select", "send", "shift", "singleton_methods", "size", "sort", "sort_by", "store", "taint", "tainted?", "to_a", "to_hash", "to_s", "type", "untaint", "update", "value?", "values", "values_at", "zip"]
i.respond_to?('keys')
=> true
i.respond_to?('get_files_in')  
=> false

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

 def get_files_in(directories)
    fail "Not a List" unless directories.instance_of?('List')
 end

 def example2( *params ) 
    lists = params.map{|x| (x.instance_of?(List))?x:nil }.compact 
    fail "No list" unless lists.length > 0
    p lists[0] 
 end

x = List.new
get_files_in(x)
example2( 'this', 'should', 'still' , 1,2,3,4,5,'work' , x )

Если вам нужен более надежный тест, вы можете попробовать RSpec для разработки, управляемой поведением.

Краткий ответ: автоматические модульные тесты и передовые методы именования.

Правильное наименование методов очень важно. Давая имя get_files_in(directory) методу, вы также даете пользователям подсказку о том, что метод ожидает получить и что он вернет взамен. Например, я не ожидал, что Potato объект выйдет из get_files_in() - это просто не имеет смысла. Имеет смысл получить только список имён файлов или, что более уместно, список экземпляров File из этого метода. Что касается конкретного типа списка, в зависимости от того, что вы хотели сделать, фактический тип возвращаемого списка не имеет особого значения. Важно то, что вы можете каким-то образом перечислить элементы в этом списке.

Наконец, вы сделаете это явным, написав модульные тесты для этого метода - показывая примеры того, как он должен работать. Так что, если get_files_in внезапно вернет Potato, тест вызовет ошибку, и вы узнаете, что первоначальные предположения теперь неверны.

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

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

Те же требования применяются к пользователю API: пользователь должен сначала выучить документацию, а затем он сможет постепенно понимать контракты и начать любить API, если контракты продуманы до мелочей (или ненавидеть его, если в противном случае).

Это связано с утиным набором текста. Контракт должен давать ключ к пониманию того, что происходит, независимо от типа входных данных метода. Таким образом, договор следует понимать более глубоко и обобщенно. Сам этот ответ может показаться немного неконкретным или даже надменным, за что я приношу свои извинения. Я просто пытаюсь сказать, что утка не ложь, утка означает, что человек думает о своей проблеме на более высоком уровне абстракции. Дизайнеры, программисты, математики - это разные имена для те же способности, и математики знают, что в математике есть много уровней способностей, когда математики следующего более высокого уровня легко решают задачи, которые тем, кто находится на более низком уровне, слишком сложно решить. Утка означает, что ваше программирование должно быть хорошим математическим, и оно ограничивает успешных разработчиков и пользователей только теми, , которые могут это сделать.

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

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

Кстати, я не знаю о Ruby, но в PHP вы можете использовать теги @phpdoc, чтобы подсказывать IDE (Eclipse PDT) типы данных, возвращаемые определенным методом.

Несколько лет назад я предпринял наполовину неудачную попытку создать что-то вроде dbc для Ruby, что может дать людям некоторые идеи о том, как продвигаться вперед с более комплексным решением:

https://github.com/justinwiley/higher-expectations