This talk is by Ben Orenstein and is about refactoring in ruby and it’s really cool
First a personal advice
If you plan to refactor anything, make sure you have tests of the class you want to refactor!
In any case, I want to summarize the main points exposed in this talk, they are:
- Public APIs with one line methods: this an advice focused on readability of the code, considering that code like this is usually conceptually better and more usable, in my opinion a good suggestion but definitely not a rule.
- Tell don’t ask: this is a OO principle that it’s about that inside a class A, don’t check for the status of an object of class B, just call the action you want the object to perform and delegate the responsibility of the state to the object. A simple code example, it means replace a code like this:
class Order ORDER_PRICE = 10.to_money def initialize(customer) @customer = customer end def charge_customer if @customer.present? customer.charge!(ORDER_PRICE) end end end
Replace it for:
class Order ORDER_PRICE = 10.to_money def initialize(customer) @customer = customer end def charge_customer customer.charge!(ORDER_PRICE) end end
But what about when the customer it’s not provided?, for that the next advice
- Null object pattern: This programming pattern could be use to delete a great amount of conditionals and use the tell don’t ask principle, the idea is have an object with the same interface to the one we want to replace when there is none, for the previous example, a null object pattern application would be
class Order ORDER_PRICE = 10.to_money def initialize(customer) @customer = customer || NullCustomer.new end def charge_customer customer.charge!(ORDER_PRICE) end end class NullCustomer def charge!(amount) end end
In this way using polymorphism we avoid the conditionals and can be specially useful with a user model, and the typical line of code
if current_user? do.... The downside, you have to keep in sync two interfaces, but the programming is so easy that this drawback is really affordable.
Don’t Be Afraid to extract terms into their own classes: it’s better explained at the video, in it the speaker replaces two date variables
DateRange.new(start, end)in this way you enforce the condition of the two dates presence and you can handle the corresponding logic in its own class.
Refactor when going to change: this sounds a great advice to me, to be more pragmatic about when to refactor and what, the idea it’s when you have to make a change to a class, make the most effort (the difficult stuff) in refactor that class, so making the change takes much less effort (the easy stuff) that originally would take.
Refactor God Objects: The speaker talks about god objects, that are the most important objects of your system and focus on them in term of refactoring and extract business logic from them, this objects are:
- highest line code models
- high change rate files
- class with frequent bugs