• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Exhibits and Presenters

Exhibits and Presenters



Briefly about Decorator, Exhibits and Presenter Patterns

Briefly about Decorator, Exhibits and Presenter Patterns



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Exhibits and Presenters Exhibits and Presenters Presentation Transcript

    • @AtifTweetsExhibits and Presenters
    • @AtifTweetsAgenda• Decorators• Exhibits• Presenters
    • @AtifTweetsDecoratorsPresentersExhibits
    • @AtifTweetsDecorators“Decorators attach additional responsibilities to an object dynamically. They provide aflexible alternative to subclassing for extending functionality.” - Design Patterns:Elements of Reusable Object-Oriented Software - GoF
    • @AtifTweetsDecorators• Decorators: The Cure for Ugly Code• Can easily add responsibility for any object• Delegate any unknown method to object itdecorates• Decorators only copy the type of thecomponent class not the behaviour• Follow open and close philosophy = Open toExtend … Close for Modifications
    • @AtifTweets
    • @AtifTweetsThe decorator pattern
    • @AtifTweetsWhy do we need this?• Only thing constant is the CHANGE• Inheritance Powerful but NOT Flexible orMaintainable design pattern• So we prefer Composition and Delegation
    • @AtifTweetsExampleexample courtesy Head First Design Patterns
    • @AtifTweetsCoffeessimo• A big coffee chain• They have some basic coffee drink types• And also customers can customize therecoffee by adding different condiments onoffer• They have coffee types: HouseBlend,DarkRoast, Espresso, Decaf• Condiment types: Milk, Mocha, Soy, Whip
    • @AtifTweetsClass Explosion
    • @AtifTweets
    • @AtifTweetsDark Roastcost()
    • @AtifTweetsDark Roastcost()Mochacost()
    • @AtifTweetsDarkRoastcost()Mochacost()WhipCost()Whip Mocha Dark Roast coffee is ready!
    • @AtifTweetsDarkRoastcost()Mochacost()WhipCost()Cost0.200.100.99€1.29
    • @AtifTweetsEspressocost()Whipcost()Dynamically created different coffees0.10 0.90Decafcost()Mochacost()0.20 1.20€1.00€1.40Whip Espresso Mocha Decaf
    • @AtifTweetsExhibits
    • @AtifTweetsExhibits• Flavor of Decorators• The primary goal of exhibits is to connect amodel object with a context for which itsrendered• Very often youll likely want to add someadditional functionality. Such is the case withexhibits. The additional functionality addedwill extend (but not disrupt) the delegateobject.
    • @AtifTweetsExhibits• Wraps a single model instance.• Is a true Decorator.• Brings together a model and a context. Exhibits needa reference to a "context" object—either a controlleror a view context—in order to be able to rendertemplates as well as construct URLs for the object orrelated resources.• Encapsulates decisions about how to render anobject. The tell-tale of an Exhibit is telling an object"render yourself", rather than explicitly rendering atemplate and passing the object in as an argument.
    • @AtifTweetsExampleclass CarExhibit < Decoratordef initialize(car, context)@context = contextsuper(car) # Set up delegationenddef additional_info"Some cars with 2 doors have a back seat, somedont. Brilliant."enddef render@context.render(self)endendclass TextRendererdef render(car)"A shiny car!#{car.additional_info}"endendclass HtmlRendererdef render(car)"A <strong>shiny</strong> car!<em>#{car.additional_info}</em>"endendclass Cardef price1_000_000endendexample courtesy mikepackdev.com
    • @AtifTweetscar = CarExhibit.new(Car.new, TextRenderer.new)car.render #=> "A shiny car! Some cars with 2 doors have a back seat, some dont.Brilliant.“car.price #=> 1000000car2 = CarExhibit.new(Car.new, HtmlRenderer.new)car2.render #=> "A <strong>shiny</strong> car! <em>Some cars with 2 doors have aback seat, some dont. Brilliant.</em>"
    • @AtifTweetsPresenters
    • @AtifTweetsa_view.html.rb<% if entry.image_url.present? %><%= render "/posts/picture_body", post: entry %><% else %><%= render "posts/text_body", post: entry %><% end %>
    • @AtifTweetsVIEW MODEL
    • @AtifTweetsPresenters• Presenters were originally formed as a morecomposite-oreinted object, but modern daypresenters are more like decorators.• Presenter deals with view and model• Clean the view by moving the logic to thepresenter class
    • @AtifTweetsVIEW MODELPRESENTERLogicMain Goal
    • @AtifTweetsSecondary GoalVIEW MODELPRESENTERHelpermethodsmethods
    • @AtifTweetsDifference b/w Exhibit and Presenters• A key differentiator between exhibits andpresenters is the language they speak. Exhibitsshouldnt know about the language of the view(eg HTML). Exhibits speak the language of thedecorated object. Presenters speak the languageof the view.• Presenters and exhibits differ in their proximityto the view. Presenters live very close to the viewlayer. In fact, they are meant to be arepresentation of the delegate object within theview.
    • @AtifTweetsPresenter in actionexample courtesy railscast.com
    • @AtifTweets
    • @AtifTweets/app/views/users/show.html.erb<div id="profile"><%= link_to_if @user.url.present?,image_tag("avatars/#{avatar_name(@user)}", class: "avatar"), @user.url%><h1><%= link_to_if @user.url.present?, (@user.full_name.present? ?@user.full_name : @user.username), @user.url %></h1><dl><dt>Username:</dt><dd><%= @user.username %></dd><dt>Member Since:</dt><dd><%= @user.member_since %></dd><dt>Website:</dt><dd><% if @user.url.present? %><%= link_to @user.url, @user.url %><% else %><span class="none">None given</span><% end %></dd><dt>Twitter:</dt>.....
    • @AtifTweets<%= link_to_if @user.url.present?, image_tag("avatars/#{avatar_name(@user)}", class:"avatar"), @user.url %>Helper Methodmodule UsersHelperdef avatar_name(user)if user.avatar_image_name.present?user.avatar_image_nameelse"default.png"endendendCondition
    • @AtifTweets/app/presenters/user_presenter.rbclass UserPresenterdef initialize(user, template)@user = user@template = templateenddef avatar@template.link_to_if @user.url.present?, @template.image_tag("avatars/#{avatar_name}", class:"avatar"), @user.urlendprivatedef avatar_nameif @user.avatar_image_name.present?@user.avatar_image_nameelse"default.png"endendend
    • @AtifTweets/app/views/users/show.html.erb<% present @user do |user_presenter|%><div id="profile"><%= user_presenter.avatar %><!-- Rest of view code omitted --></div><% end %>module ApplicationHelperdef present(object, klass = nil)klass ||= "{object.class}Presenter".constantizepresenter = klass.new(object, self)yield presenter if block_given?presenterendend
    • @AtifTweetsFurther learning• Head First Design Patterns di Eric Freeman,Elisabeth Freeman, Kathy Sierra e Bert Bates• Design Patterns in Ruby di Russ Olsen• Design Patterns for Dummies• Objects on Rails by Avdi Grimm• http://mikepackdev.com/blog_posts/31-exhibit-vs• http://railscasts.com/episodes/287-presenters-fro
    • @AtifTweetsGrazie!