Преимущества / недостатки использования struct в качестве параметра при определении нового API

Question

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

Является ли хорошей идеей иметь API в виде:

API1 (abc, def, ....) API2 (abc, def, ....) и т. д.

или я должен определить структуру с полями, чтобы помочь с будущими изменениями?

Любые другие идеи приветствуются!

Answer 1

Для продолжения того, что описывает mu, вы увидите, что в обычной идиоме Ruby метод устанавливает для себя некоторые параметры по умолчанию, а затем объединяет в этот хэш параметры, полученные методом.Таким образом, вы можете быть уверены, что всегда существует некоторый минимальный список опций:

def self.api1(options={})
  default_options = { :foo => 'bar', :baz => nil }
  options = default_options.merge options
  # Now include your code and you can assume that options[:foo] and options[:bar] are there
end

Это удобно, например, когда ваш метод выводит значение :baz.Теперь вам не нужно проверять, существует ли он первым, вы можете просто вывести его, зная, что он всегда будет существовать.

Answer 2

Использование структуры было бы странно в Ruby, хэш был бы нормальным:

def self.api1(options)
    # Look at options[:abc], options[:def], ...
end

И тогда он может быть вызван с использованием именованных аргументов, таких как:

C.api1 :abc => 'abc', :def => '...'

Простота расширения, обычная практика Ruby и некоторые дополнительные параметры.