Notes from LA Ruby Conf 2013 talks - Refactoring Fat Models with Patterns

refactoring-models-with-patterns.md

Refactoring Fat Models with Patterns

• @brynary
• https://github.com/codeclimate/refactoring-fat-models

Anti-Pattern

Extract Mixins (modules)

• harder to refactor

Patterns

Value Objects

• repeated word/suffix means extract value object

Service Objects

• example: extract controller side*effects into service for reuse (DRY)

Form Objects

• company method is a shapeshifter method (sometimes a string, sometimes an object)
• cannot create a user w/o a company
• can leave database in an unknown state
• validations are dependent on context and can change over time
• keep signup specific validations in the form object

Query Objects

• encapsulate a single way to query the database
• define a class responsible for executing one, and only one, query
• class methods make refactoring harder. use first class objects
• where to put it? it doesn't matter! moving correct objects to new directories is a first world problem

View Objects

• keep non*critical concerns out of the critical path of the user
• keeps logic out of the helper
• this implements two step view pattern (helps with complexity in view layer)

Policy Objects

• very important domain concept being hidden in a domain model
• methods in an object should be related
• makes it easy to layer business rules on top of other business rules

Decorators

• not a core behavior of the objects lifecycle
• the interface still quacks like an order
• code that wires code is separate from code that does work
• check out gems like draper for decorating views

Questions

• thought: the problem with rewrites is that features and complexity are already high. requires a lot of up front architecture.
• good design and architecture is iterative and incremental
• why do we still have 3,000 line active record models?
• not enough experience to know when to refactor
• rushing for a deadline