Fat Models Must Die

Il concetto “Fat Models, Skinny controller” è da sempre uno dei cavalli di battaglia di Rails ed è uno dei principi fondamentali intorno a cui ruota il suo stack. Purtroppo, seguire ciecamente questo pattern spesso porta ad una crescita smisurata delle responsabilità dei modelli, che col passare del tempo e dei commit si trasformano in matasse di codice ingarbugliato e ingestibile.

In questo talk verranno esplorate differenti metodologie che si possono seguire nella pratica per mantenere il controllo del proprio progetto. Si descriveranno i pattern più diffusi proposti dalla community Rails per risolvere il problema della crescita del codice nel medio-lungo periodo: incominciando con concerns e presenters per passare a service objects e DCI, verranno spiegati i pregi dell’utilizzare pratiche più OOP per gestire con soddisfazione la complessità delle nostre applicazioni.

Lanyrd: http://lanyrd.com/2013/rubyday13/sckdyg/

Transcript

1. fat models MUST DIE @arkham @steffoz
2. let’s talk about Rails
3. Model View Controller
4. Skinny controller, fat model
5. $ wc -l app/models/* | sort -rn | sed -n '2,4p' 625 app/models/activity.rb 407 app/models/task.rb 364 app/models/user.rb
6. Owners Of our application business logic
7. Knows too much or does too much God Object
8. Is it wrong?
9. Software Design
10. Robert C. Martin Uncle Bob © Mike Clark
11. Two values of software
12. Software meets the current needs of the current user 2nd value
13. wait,
14. Software is easy to change 1st value
15. Agile
16. SOLID Principles
17. Single Responsibility Principle
18. SRP Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
19. A class should have one, and only one, reason to change SRP
20. let’s talk about Rails (again)
21. ActiveRecord::Base Persist and represent DB rows
22. Control HTTP requests/ responses at high level ActionController::Base
23. Where do we put business logic?
24. ActiveSupport::Concern
25. require 'active_support/concern' module NameGreeter extend ActiveSupport::Concern included do attr_accessor :name end def greet puts "Hi! I'm #{name}!" end module ClassMethods def build(name) self.new.tap do |instance| instance.name = name end end end end class User include NameGreeter end user = User.build("Mark") user.greet >> “Hi! I’m Mark!”
26. class Document < ActiveRecord::Base include Taggable include Visible include Dropboxed include Omasake end
27. app/models/concerns app/controllers/concerns Rails 4
28. Logic separation
29. Code reuse
30. Rails Drama
31. Models are still God Objects! Runtime
32. class User include NameGreeter end User.ancestors.include? NameGreeter >> true
33. Mixins are a form of Inheritance
34. Gang of Four Favor object composition to class inheritance
35. is-a Inheritance has-a Composition A cat is a pet A cat has a tail
36. Easier to change
39. OOP in RUBY
40. OOP I did it again
43. We need to calculate stats about football matches Scenario
44. class Match < ActiveRecord::Base def first_half_win? fh_made > fh_taken end def second_half_win? sh_made > sh_taken end def first_half_loss?; ... ; end def second_half_loss?; ... ; end def first_half_draw?; ... ; end def second_half_draw?; ... ; end end
45. Value Object
46. Equality is dependent on their value rather than an identity Property
47. class Score < Struct.new(:goals_made, :goals_taken) def win? goals_made > goals_taken end def draw? goals_made == goals_taken end def loss? goals_made < goals_taken end end
48. class Match < ActiveRecord::Base def first_half_score Score.new(fh_made, fh_taken) end def second_half_score Score.new(sh_made, sh_taken) end end
49. Struct #hash #eql?
50. We are closing an e- commerce purchase using Order, Customer and Product objects Scenario
51. Action is complex
52. Action reaches across multiple models
53. Action interacts with external services
54. Command Object a.k.a. Services
55. class ItemsController < ApplicationController def add_to_cart item = Item.find(params[:id]) AddToCart.new(current_user, item).execute! end end
56. class AddToCart < Struct.new(:user, :item) def execute! cart.add_item!(item) end private def cart user.active_cart end end
57. Encapsulate all the logic for a specific scenario
58. Reuse logic in multiple contexts
59. Filter events by full-text search, distance and category Scenario
60. class EventsController < ApplicationController def index @events = Event.published if params[:lat] && params[:lng] && params[:distance] @events = @events.near(lat, lng, distance) end if params[:query].present? @events = @events.matching(params[:query]) end if params[:category_id].present? @events = @events.in_category(params[:category_id]) end end end
61. Query Object
62. Responsible for returning a result set based on business rules Purpose
63. class EventsQuery < OpenStruct def scope(scope = Events.scoped) scope = scope.published if lat && lng && distance scope = scope.near(lat, lng, distance) end if query.present? scope = scope.matching(query) end if category_id.present? scope = scope.of_category(category_id) end scope end end
64. class EventsController < ApplicationController def index @events = EventsQuery.new(params[:query]).scope end end
65. DRY up your views
66. class EventsQuery < OpenStruct include ActiveModel::Conversion extend ActiveModel::Naming def persisted? false end # ... end
67. <%= form_for @query, as: :query, url: events_path, method: :get do |f| %> <%= f.text_field :query %> <% # ... %> <% end %>
68. Send mail notifications after the creation of new comments Scenario
69. class Comment < ActiveRecord::Base after_create :send_notification! private def send_notification! AppMailer.comment_submission(self).deliver end end
70. Model hooks are for data integrity
71. Do we always want notifications?
72. Command Object!
73. Decorator
74. Proxy
75. class CommentsController < ApplicationController def create @comment = Comment.new(params[:comment]) if @comment.save redirect_to blog_path, notice: "Comment was posted." else render "new" end end end
76. class CommentsController < ApplicationController def create @comment = Notifier.new(Comment.new(params[:comment])) if @comment.save redirect_to blog_path, notice: "Comment was posted." else render "new" end end end
77. class Notifier < Struct(:comment) def save comment.save && send_notification! end private def send_notification! AppMailer.comment_submission(comment).deliver true end end class Comment < ActiveRecord::Base end
78. Exhibit a.k.a. Presenter
79. The primary goal of exhibits is to insert a model object within a rendering context. Purpose
80. It’s a decorator Unrecognized messages are passed through to the underlying object
81. Augment models behaviour when it is needed
82. = link_to @user.full_name, @user = raw sanitize(@user.bio) = image_tag(@user.gravatar_url)
83. - user = UserPresenter.new(@user, self) = user.link_to = user.bio = user.gravatar
84. require 'delegate' class UserPresenter < SimpleDelegator def initialize(user, context) @context = context super(user) # Set up delegation end def gravatar_url md5 = Digest::MD5.hexdigest(email.downcase) "http://gravatar.com/avatar/#{md5}.png" end def gravatar @context.image_tag(gravatar_url) end end
85. Seamless integration
86. OOP alternative to Rails helpers
87. DCI Data, Context & Interaction
88. Separate what the system is (data) from what the system does (behaviour). Purpose
89. Use case
90. Context Roles
91. Transfer money between two accounts Scenario
92. class Account < Struct.new(:owner, :balance) end account = Account.new("Bob", 500.0)
93. bob_account = Account.new("Bob", 100.0) alice_account = Account.new("Alice", 50.0) context = MoneyTransferContext.new( bob_account, alice_account ) context.transfer(10.0) puts bob_account.amount # => 90.0 puts alice_account.amount # => 60.0
94. class MoneyTransferContext < Struct.new(:source, :destination) module SourceRole def withdraw(amount) self.balance -= amount end end module DestinationRole def deposit(amount) self.amount += amount end end end
95. #extend
96. bob_account = Account.new("Bob", 100.0) alice_account = Account.new("Alice", 50.0) bob_account.extend SourceRole bob_account.withdraw(amount) # => 90.0 alice_account.withdraw(amount) # NoMethodError: undefined method...
97. class MoneyTransferContext < Struct.new(:source, :destination) # ... def transfer(amount) source.extend SourceRole destination.extend DestinationRole source.withdraw(amount) destination.deposit(amount) end end
98. Domain model Use case Role Data Context Interaction
99. Give first-class status to system behavior
100. Improved spatial locality
101. ENOUGH.
102. Recap
103. Rails is great!
104. MVC/ActiveRecord cannot solve everything
105. When in doubt, Composition is your ally
106. Don’t be afraid of new objects
107. Think of Rails as a dependency
108. Whatever works best in your domain!
109. Sandi Metz Practical Object Oriented Design in Ruby © Sebastian Delmont
110. Classes can be no longer than one hundred lines of code. 1st rule
111. Methods can be no longer than five lines of code. 2nd rule
112. Pass no more than four parameters into a method. Hash options are parameters. 3rd rule
113. Controllers can instantiate only one object. 4th rule
114. It’s tough, but rewarding!
115. Questions! @arkham @steffoz http://workshop.welaika.com