Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Refactoring Fat Components (with Ruby on Rails examples)

Refactoring Fat Components (with Ruby on Rails examples)

When starting a project it's usually easy to find stuff, read and understand the code even if it's not super organized, but as the time goes by and the codebase gets bigger, usually the development team gets bigger too, things can become quite messy.
- What are fat components (specially models) and why is it a problem
- Ways to extract logic out of models into dedicated objects

Tutti Quintella

October 24, 2018

More Decks by Tutti Quintella

Other Decks in Programming


  1. 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
  2. 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
  3. What are Fat Components? • Too much logic in the

    same place • Too many responsibilities in the same component
  4. 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
  5. 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
  6. Sometimes only M, V and C is not enough... •

    Fat Controllers • Fat Models • Too much logic in one place
  7. 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...
  8. Ways to extract logic • Mixins • Value objects •

    Service objects • Form objects • Policy objects • Query objects
  9. 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?
  10. 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...
  11. 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
  12. 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
  13. 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)
  14. Others • Policy objects (define rules / complex validations for

    other models) • Query objects (objects to perform complex queries, that depend on multiple relations) • etc...
  15. THANK YOU Contact: - Email: [email protected] - Facebook: https://fb.me/tuttiquintella -

    Twitter: @tuttiq - Github: @tuttiq - LinkedIn: https://linkedin.com/in/tuttiquintella