Лучшая практика для упаковки сторонней службы в библиотеке

Question

Я заинтересован в написании библиотеки для стороннего API, которым я пользуюсь, и мне нужен совет.Среднее использование библиотеки будет включать в себя несколько вызовов API в одном запросе.Например, один вызов API для захвата пользователя из сторонней службы, а затем другой вызов для использования этого пользователя для получения его / ее фотографий.Каждый вызов API получит свою собственную оболочку метода библиотеки с дополнительной логикой для обработки ошибок / тайм-аутов, но мой самый большой вопрос заключается в том, должна ли библиотека создаваться как одноэлементный объект, содержащий состояние, или просто как серия методов класса.

Например:

user_id = ThirdParty.get_user("abc@gmail.com")
photos = ThirdParty.get_photos(user_id)

ИЛИ

thirdpartyservice = ThirdPartyService.new("abc@gmail.com")
photos = thirdpartyservice.get_photos

Это не обязательно точный дизайн библиотеки, но меня просто смущают плюсы и минусы каждого подхода,Любая помощь будет потрясающей!

Кстати, я использую ruby!

Answer 1

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

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

Чтобы добавить fleixiblity для метода get_photos, вы можете сделать что-то вроде:

class ThirdPartyService

  def get_photos(user_id=@id_stored_in_library)
    # do work
  end

end

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

Answer 2

Вам нужно состояние (хост и т. Д.) И поведение, основанное на этом состоянии, поэтому вы должны использовать объекты, а не один одноэлементный объект.

Как уже упоминалось, вы не должны называть методы, такие как get_photos, просто photos.

Answer 3

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

Хотя наследование на самом деле не требуется в языке динамической / утиной типизации, таком как Ruby, это может помочь конкретизировать «почему».

class MailProvider 

  def initialize(args); raise "Not Implemented"; end

  def send_mail(args); raise "Not Implemented"; end

end

class SendGridService < MailProvider

  def initialize(args)
    # Use args here
  end

  def send_mail(args)
    # Use SendGrid's API or Gem here
  end

end

Тогда в вашем коде вы можете получить что-то вроде этого:

config.mail_provider = SendGridService.new({
  username: ENV['SENDGRID_USERNAME'],
  password: ENV['SENDGRID_PASSWORD']
})

config.mail_provider.send_mail({ subject: 'woot', message: 'Look ma, I did it!' })

Затем шесть месяцев спустя, когда ваши пользователи любят вашу Gem / библиотеку, но хотят поддержки MailChimp, вы можете просто создать вторую службу «MailChimpService» и позволить своим клиентам использовать нового провайдера.

Answer 4

Вместо методов get_ set_ будет лучше использовать геттеры и сеттеры.Это стандарт ruby ​​(не уверен, но методы get_ и set_, которые я видел только один раз в коде ruby).

Если вам не нужно сохранять состояние между запросами, сделайте его статическим.Но это зависит от многих факторов.Можете ли вы сказать нам, какой API вам нужно обернуть?