I love this particular pattern. It solves the problem where simply including a module as mixin does not provide sufficient configuration for the mixed-in functionality to accomplish its job. I’ve found it most useful for library writing, wherein not only do you need that extra configuration, but where you’d like to be able to warn the user of your library that they have failed to supply adequate configuration.
This contrasts with the other Ruby-ism seen used to accomplish mixin-plus-configuration: Requiring the programmer to call specific macro-style class methods after including the module. You, as the author of the mixin, can’t be sure at include time if your required configuration will be soon supplied, or never supplied, and you have to wait until they try to use your module before you can do warn them about it.
Except you probably don’t do anything defensive and warn them, because writing defensive wrappers for every method that checks every config setting gets old fast. The likely situation is instead that the code will eventually throw some exception internally, and the exception is something that (hopefully?) leads the hapless user of your library to re-read your docs.
I love this particular pattern. It solves the problem where simply including a module as mixin does not provide sufficient configuration for the mixed-in functionality to accomplish its job. I’ve found it most useful for library writing, wherein not only do you need that extra configuration, but where you’d like to be able to warn the user of your library that they have failed to supply adequate configuration.
This contrasts with the other Ruby-ism seen used to accomplish mixin-plus-configuration: Requiring the programmer to call specific macro-style class methods after including the module. You, as the author of the mixin, can’t be sure at include time if your required configuration will be soon supplied, or never supplied, and you have to wait until they try to use your module before you can do warn them about it.
Except you probably don’t do anything defensive and warn them, because writing defensive wrappers for every method that checks every config setting gets old fast. The likely situation is instead that the code will eventually throw some exception internally, and the exception is something that (hopefully?) leads the hapless user of your library to re-read your docs.
Blurring the line between a Class and a Module does make the code more succinct but quite difficult to follow.