Refactoring Fat ModelsTrying to be a Software Engineer

Copyright 2015. Jyaasa Technologies. All Rights Reserved http://jyaasa.com

By: Shiva Bhusal

Things a Software Engineer should have grasp of

- Concept of Object Orientation

- Why we moved from functional programming ?

- Some OO Design Principles

- S.O.L.I.D

- Single Responsibility

- Open / Closed

- Liskov Substitution Principle

- Interface Segregation

- Dependency Inversion

http://jyaasa.com

What is the Responsibility of ActiveRecord

• ActiveRecord classes handle persistence, associations and not much else.

• But eventually they grow and become de facto owner of all the Business Logic

• Now at the time the product ships you have over 500 lines in User Model

• 100 s of methods in public interface

http://jyaasa.com

Whose fault is this?

• Is it Rails’s fault?

• it is said Rails impede OOP

• But is it 100% true?

• Or It's your fault?

• Yes, Rails lack some other layer of Abstraction that Other frameworks have

http://jyaasa.com

Now how to transform??

http://jyaasa.com

Beware!

Don’t Extract Mixins from Fat Models

“Any application with an app/concerns directory is concerning.”

then what??

- Prefer composition to inheritance

http://jyaasa.com

Extract Service Objects

Reach for Service Objects when an action meets one or more of these criteria:

• The action is complex (e.g. closing the books at the end of an accounting period)

• The action reaches across multiple models (e.g. an e-commerce purchase using Order,CreditCard

and Customer objects)

• The action interacts with an external service (e.g. posting to social networks)

• The action is not a core concern of the underlying model (e.g. sweeping up outdated data after a

certain time period).

• There are multiple ways of performing the action (e.g. authenticating with an access token or

password). This is the Gang of Four Strategy pattern.

http://jyaasa.com

http://jyaasa.com

Extract Policy Objects

• Sometimes complex read operations might deserve their own objects

• Policy Objects are similar to Service Objects, but I use the term “Service Object” for write operations

and “Policy Object” for reads

• Policy Objects operate on domain models already loaded into memory.

http://jyaasa.com

• This Policy Object encapsulates one business rule,

• that a user is considered active if they have a confirmed email address and have logged in within

the last two weeks.

• You can also use Policy Objects for a group of business rules like an Authorizer that regulates which

data a user can access.

http://jyaasa.com

Use Decorator

• Draper adds an object-oriented layer of presentation logic to your Rails application.

• If logic is needed purely for display purposes, it does not belong in the model

• The decorator wraps the model, and deals only with presentational concerns.

• In the controller, you decorate the article before handing it off to the view:

Decorators are the ideal place to:

• format complex data for user display

• define commonly-used representations of an object, like a name method that combines first_name and

last_name attributes

• markup attributes with a little semantic HTML, like turning a url field into a hyperlink http://jyaasa.com

# app/controllers/articles_controller.rb

def show

@article = Article.find(params[:id]).decorate

end

http://jyaasa.com

Extract Form Objects

When multiple ActiveRecord models might be updated by a single form submission

http://jyaasa.com

Sources

https://github.com/drapergem/draper

http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

http://jyaasa.com

Any Queries ?

• Forward your queries to web@jyaasa.com

•Alternatively, you can tweet us your queries @jyaasa on Twitter

http://jyaasa.com