You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What parameters should go in the initialisation method? Objects that "be" VS Objects that "do"
What parameters should go in the initialisation method? Objects that "be" VS Objects that "do"
Tim Riley has a great rule of thumb for classifying objects and deciding what parameters should be part of the class' attributes (state) VS which should be provided as arguments to the methods of that class.
There are 2 types of Objects: Objects that "be" and Objects that "do".
Objects that "be"
If you say "this object IS a dog", then you are dealing with an object that "be".
The job of these objects are to represent data in our application. They hold data in their state and therefore we must
Dependency Injection with defaults in Ruby by overriding the new method
Dependency Injection with defaults in Ruby by overriding the new method
This technique his heavilly inspired by Tom Dalling's Dependency Injection Containers vs Hard-coded Constants
article. In particular, it proposes an alternative implementation of his "Hybrid Approach" using a build class method.
The main problems with Tom's implementation using build
It introduces a new way of instantiating objects via the .build method. This new API requires other developers to be aware that they must use .build if they want an instance of the object with default dependencies.
Following from the point above, in cases where we want to use cascading default dependencies, we must remember to use the dependencies .build method to benefit from their default behaviour.