Ruby Gem Configuration Patterns

This is actually a very complicated way of achieving the goal. It works, but it&#x27;s not good from an economic point of view as it is more expensive in computational terms than a simpler OO alternative, which is to pass the size when you instantiate the MegaLotto::Drawing object.<p>For example, compare the proposed solution:<p><pre><code> MegaLotto.configure do |config| config.drawing_count = 10 end MegaLotto::Drawing.new.draw </code></pre> With the alternative:<p><pre><code> MegaLotto::Drawing.new(10).draw </code></pre> If you want to make it extensible, you can use keyword arguments:<p><pre><code> MegaLotto::Drawing.new(size: 10).draw </code></pre> The interface and the implementation are simpler, but also the performance is better because there are less method calls. If you look at the code of both implementations, you will find the simpler one easier to understand. As a side effect, you will also get simpler stack traces if anything goes wrong.

I wish people would stop doing this.<p>It generally means down the road I find myself wanting to use two different configurations and everything explodes in my face because the author of the gem thought there would always be exactly one configuration.<p>What is wrong with<p><pre><code> MegaLotto.new do |lotto| lotto.drawing_count = 10 end </code></pre> and just wrapping it in a &quot;default_megalotto&quot; factory method?

This is a great approach for setting config variables. I also like to enable the user to add custom functionality to the gem by accepting a block that is called with any relevant variables for the user to access.<p>For example, in Exceptionally[1], the user can add an initializer that looks like:<p><pre><code> Exceptionally::Handler.before_render do |message, status, error, params| # put any code here end </code></pre> In the gem, this translates to:<p><pre><code> def self.before_render(&amp;block) &amp;&amp;callback = Proc.new(&amp;block) end </code></pre> The gem can then call the user&#x27;s block and give it access to the same variables the rest of the gem does. This approach is a lot simpler than setting up an entire Middleware stack, as suggested in the blog, and makes more sense for simpler gems.<p>1: <a href="https://github.com/neilgupta/exceptionally" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;neilgupta&#x2F;exceptionally</a>

This is a good overview of a config pattern. I&#x27;d personally have preferred it without the TDD stuff, seems to get in the way of the explanation.

Check out my configuration gem.<p><a href="https://github.com/GeorgeErickson/bonfig/" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GeorgeErickson&#x2F;bonfig&#x2F;</a>