Конфигурируем Ruby модуль

[printercu]

Зачем использовать приватный сеттер вместо @config=?

[kirillplatonov]

Вы правы, незачем. Обновил исходники.

[printercu]

В последней реализации reset потерялся.

[kirillplatonov]

Он не потерялся. Я поместил его объявление в тестовый класс ConfigurationTest gist.github.com/kirillplatonov/78c373be9f47f3944472#file-gistfile1-rb-L27 Он нужен только для тестирования и не должен быть частью публичного API.

[northbear]

Отдельный класс на мой вкус избыточно. Для значений по умолчанию я делаю так:

module Sample
  DefaultConfig = Struct.new(:a, :b) do
    def init
      self.a = 10
      self.b = 'test'
      self
    end
  end

  def self.configure
    @config = DefaultConfig.new.init
    yield(@config) if block_given?
    @config
  end

  def self.config
    @config || configure
  end
end

[northbear]

Хех… Надо же, только сейчас сообразил, что вместо метода init в Struct'e, можно определить метод initialize. Тогда код короче:

module Sample
  DefaultConfig = Struct.new(:a, :b) do
    def initialize
      self.a = 10
      self.b = 'test'
    end
  end

  def self.configure
    @config = DefaultConfig.new
    ... 

[kirillplatonov]

Уже собрался вам писать ответ про инициализатор) Хороший вариант. Лаконичный. Добавлю его в пост.

[akzhan]

Более удобно, когда кофиг предоставляет себя, как self, а вместо сеттеров — обычные методы. Например, как в Opscode Chef Recipes.

Гораздо лаконичнее получается.

Пример,

LikeCarrierWave.configure do
  storage :file
  enable_processing false
end

[northbear]

Удобнее разве, что отсутствием присваивания. Но в коде модуля много лишних телодвижений придется делать, заморачиваться с method_missing…
Учитывая, что конфигурирование модуля это практически разовое действие для одного проекта, то овчинка выделки не стоит, imho…

[akzhan]

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