In the early stages of a project object creation is simple and dependencies are kept to a minimum. As the project grows so does the complexity of object creation and its dependencies. It doesn’t make sense to create custom factory classes upfront to deal with complex object construction that may not exist yet. But when those custom factories are needed it is usually painful and time consuming to update the code base to use them. It’s also easy for developers to give-in due to time constraints and start making bad decisions.
This is where FactoryLoader comes into play. It automatically creates a Factory class for your objects and provides a create method which passes any arguments along to your object’s constructor.
When you need to have custom factory behavior you can implement the factory without having to update other code references (assuming you’ve used the factory in the rest of your application rather then direct class references).
project/
init.rb
lib/
|--things/
|-- foo.rb
|-- bar.rb
|--factories/
|-- bar_factory.rb
Given the above project directory structure you could have the following code in init.rb:
factory_loader = FactoryLoader.new("lib/factories")
factory_loader.load("lib/things")
The first call constructs a factory loader telling it which directory is used to store developer-written custom factories.
The second call will create an in-memory factory class for each *.rb file in the lib/things/ directory. A FooFactory class will be created to correspond with the foo.rb file. The generated factory will provide a create method which will pass along all arguments to the constructor of the object it wraps. So…
FooFactory.new.create :a => :b
is the same as:
Foo.new :a => :b
Even though a bar.rb file exists a BarFactory will NOT be created. This is because we told the FactoryLoader that custom factories are storied in lib/factories/ and a bar_factory.rb file exists there, so FactoryLoader assumes you want to use a custom factory. It also assumes that the class inside of bar_factory.rb is BarFactory.
FactoryLoader dynamically creates the factory classes — they are not written to disk. FactoryLoader also uses file naming conventions to determine what to do. For example:
foo.rb => FooFactory
crazy_dolphins.rb => CrazyDolphinsFactory
Factory.new
The dynamically created factories are classes and create is an instance method on them. You have to construct a factory in order to use it. This is so the factories themselves can be easily used in dependency injection frameworks.
Making a custom factory
So you’re using FactoryLoader to do the work of creating factories for you. Let’s say our Foo object now has some creation logic that we do not want in Foo’s constructor. To put it in the FooFactory just create the file in lib/factories/foo_factory.rb. The contents of foo_factory.rb might look like:
class FooFactory
def create options={}
if business_logic_passes?
Foo.new options
else
raise "business logic failed"
end
end
end
Install it!
gem install -r factory_loader
More Info
- RDOC: “http://mhs.rubyforge.org/factory_loader/rdoc/”:http://mhs.rubyforge.org/factory_loader/rdoc/
- Public git repository: “git://github.com/zdennis/factory_loader.git”:git://github.com/zdennis/factory_loader.git
- Homepage: “www.continuousthinking.com/factory_loader”:www.continuousthinking.com/factory_loader
Author
Me, Zach Dennis
Special Thanks
- Dave Crosby at Atomic Object
- Ryan Fogle at Atomic Object
blog comments powered by Disqus