Refactoring Fat Components With Ruby on Rails examples 

Who am I? ● Tutti Quintella (@tuttiq online) ● From São Paulo, Brazil ● Major in Computer Engineering ● Software Engineer since 2011 ● Software Engineer @ Mercari ● Director @ Women Who Code Tokyo 

DEAR WOMEN, WE NEED YOU https://meetup.com/Women-Who-Code-Tokyo/ 

Disclaimer ● This presentation touches controversial topics like: ○ Code readability ○ Design patterns ○ Coding principles / "good practices" ● Most of the content is opinion based and subjective to exceptions / counter-arguments 

What are Fat Components? ● Too much logic in the same place ● Too many responsibilities in the same component 

Problems of fat components ● Harder to find logic when looking at the file structure ● Harder to read and understand what a component does ● Components are too specific and less reusable ● Harder to break the app in separate modules ● Harder to unit test 

Design patterns ● Splitting the code into smaller parts ● More defined responsibilities ● Well known patterns: easier to find people that already know them, or easier to find learning resources 

Design patterns - MVC Image copyright by Sandro Mancuso at Codurance 

Sometimes only M, V and C is not enough... ● Fat Controllers ● Fat Models ● Too much logic in one place 

First advice "Skinny controllers, fat models" "Controllers should only concern themselves with receiving data from the client and passing data to the views. Logic should be on the models" Result: Skinny controller, OBESE models. User.rb - 700+ lines... 

Single Responsibility Principle SOLID ↪ Single Responsibility Principle: a class should have only a single responsibility 

Ways to extract logic ● Mixins ● Value objects ● Service objects ● Form objects ● Policy objects ● Query objects 

Mixins ● Pulling sets of methods out of a large model into a module/interface: makes the model smaller, but does it really organize the logic? 

Mixins (properly implemented) 

Value Objects ● Most languages already have some native value objects like Date, Time, URI, File. ● Any attributes that are more than basic strings or numbers are good candidates to be domain specific value objects ● Ex: Phone, Address, Currency, Rating, Score, Color... 

Value Objects 

Service Objects Moving actions to objects dedicated only to perform them. Good candidates: ● Actions that reach across multiple models ○ E.g.: User + Order + CreditCard to perform a purchase ● Actions that interact with external services / APIs ○ E.g.: FacebookAPI Service 

System design: Service Objects Moving actions to objects dedicated only to perform them. Good candidates: ● Actions that are not a core concern of the underlying model ○ E.g.: data cleanup, parsing, normalization... ● Actions that can be performed in multiple ways (Strategy pattern) FileParser XML Parser JSON Parser 

System design: Service Objects 

Form Objects ● Form Objects are useful (and recommended) when a form doesn't map directly and simply to a single model. E.g: ○ Data needs parsing or formatting ○ Data has complex validations ○ More than one model are updated through the same form (nested models) 

Form Objects 

Others ● Policy objects (define rules / complex validations for other models) ● Query objects (objects to perform complex queries, that depend on multiple relations) ● etc... 

Bonus: Breaking down the architecture microservices.io 

THANK YOU Contact: - Email: [email protected] - Facebook: https://fb.me/tuttiquintella - Twitter: @tuttiq - Github: @tuttiq - LinkedIn: https://linkedin.com/in/tuttiquintella