Notes by: Sergio Rodriguez Book by: Sandi Metz
- Changes in applications are unavoidable.
- Change is hard because of the dependencies between objects
- The sender of the message knows things about the receiver
Notes by: Sergio Rodriguez Book by: Sandi Metz
Imagine you have some type of demo that needs to reset itself once a day.
Install the Database Cleaner Gem and make sure you make it available for the production environment.
Create a lib/tasks/scheduler.rake
file that looks similar to this
desc "This task is called by the Heroku scheduler add-on to reset the demo"
task :reset_demo => :environment do
puts "Cleaning Up The DB..."
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.
.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..build
method to benefit from their default behaviour.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".
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
This work is related to my post about the status of encrypted credentials support in Rails 6 that is part of the "A May of WTFs" initiative.
In particular, it identifies the documentation gaps that exist in Rails' 6.0.3.1 guides related to encrypted credentials.