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

Transcript

1. Refactoring Fat Components
   With Ruby on Rails examples
   

   View Slide

2. 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
   

   View Slide

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

   View Slide

4. 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
   

   View Slide

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

   View Slide

6. 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
   

   View Slide

7. 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
   

   View Slide

8. Design patterns - MVC
   Image copyright by Sandro Mancuso at Codurance
   

   View Slide

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

   View Slide

10. 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...
    

    View Slide

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

    View Slide

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

    View Slide

13. 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?
    

    View Slide

14. Mixins (properly implemented)
    

    View Slide

15. 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...
    

    View Slide

16. Value Objects
    

    View Slide

17. 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
    

    View Slide

18. 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
    

    View Slide

19. System design: Service Objects
    

    View Slide

20. 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)
    

    View Slide

21. Form Objects
    

    View Slide

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

    View Slide

23. Bonus: Breaking down the architecture microservices.io
    

    View Slide

24. THANK YOU
    Contact:
    - Email: q.tuane@gmail.com
    - Facebook: https://fb.me/tuttiquintella
    - Twitter: @tuttiq
    - Github: @tuttiq
    - LinkedIn: https://linkedin.com/in/tuttiquintella
    

    View Slide