Как стать автором
Обновить

Комментарии 10

Зачем использовать приватный сеттер вместо @config=?
Вы правы, незачем. Обновил исходники.
В последней реализации reset потерялся.
Он не потерялся. Я поместил его объявление в тестовый класс ConfigurationTest gist.github.com/kirillplatonov/78c373be9f47f3944472#file-gistfile1-rb-L27 Он нужен только для тестирования и не должен быть частью публичного API.
Отдельный класс на мой вкус избыточно. Для значений по умолчанию я делаю так:

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
Хех… Надо же, только сейчас сообразил, что вместо метода 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
    ... 
Уже собрался вам писать ответ про инициализатор) Хороший вариант. Лаконичный. Добавлю его в пост.
Более удобно, когда кофиг предоставляет себя, как self, а вместо сеттеров — обычные методы. Например, как в Opscode Chef Recipes.

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

Пример,

LikeCarrierWave.configure do
  storage :file
  enable_processing false
end

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