Isn’t the last stage of grieving acceptance?

In episode #10 of the Giant Robots Smashing into other Giant Robots podcast, Ben Orenstein is joined by Joe Ferris and Mike Burns.

They start off with some recommendations for awesome programming books and then dive right in to questions about not following “Tell don’t ask” in the view, how MVC and the Single Responsibility Principle may be at odds with “Tell don’t ask” in the view, and what a more object oriented approach may look like. They also discuss “Class-oriented programming”, what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike’s experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast!

• Listen Now (43 minutes, 20.7MB mp3)
• Subscribe via RSS
• Subscribe in iTunes

To have us answer your questions on the air

Email your questions to info@thoughtbot.com or tweet to us @thoughtbot.

Notes & Links

• Structure and Interpretation of Computer Programs
• MIT course that everyone failed
• Growing Object-Oriented Software, Guided by Tests
• Clean Code: A Handbook of Agile Software Craftsmanship
• Tell Don’t Ask
• Single Responsibility Principle
• Shotgun Surgery
• Smalltalk, Squeak
• Scala, Play framework

Upcoming Events

• Rocky Mountain Ruby, September 19-22, “Refactoring from Good to Great”
• Frozen Rails in Helsinki Finland, September 20-21, “When Not to Use Object-Oriented Techniques”
• View all events we’ll be at…

Follow @thoughtbot, @r00k, @joeferris, @mikeburns on twitter.

Role Suggesting Name

Consider a CreditCard class:

class CreditCard < ActiveRecord::Base
  belongs_to :brand_manager, class_name: 'User'
end

class User < ActiveRecord::Base
  has_many :credit_cards, foreign_key: 'brand_manager_id'
end

It is used like this:

brand_manager.credit_cards
credit_card.brand_manager

User in this context would be too generic. In the domain-specific language of this application, the people with credit cards are referred to as “brand managers”.

Why not name the model BrandManager?

In this case, User is overloaded to handle three different roles using simple flags on the model. This allows us to use Clearance normally and keeps authentication and standard user vocabulary available where it makes sense.

class Impression < ActiveRecord::Base
  belongs_to :campaign, class_name: 'Offer'
end

In this example, the object plays two different roles depending on to whom it is being displayed. The object is an offer to recipients but its Role Suggesting Name is campaign to advertisers and impressions.

Learn more about Role Suggesting Name in Philippe Hanrigou’s talk, What the Ruby craftsman can learn from the Smalltalk master.

Written by Dan Croak.