{"id":17,"date":"2007-02-12T23:27:16","date_gmt":"2007-02-12T22:27:16","guid":{"rendered":"http:\/\/schuerig.de\/michael\/blog\/index.php\/2007\/02\/12\/self-conscious-decoration\/"},"modified":"2021-11-24T09:20:10","modified_gmt":"2021-11-24T08:20:10","slug":"self-conscious-decoration","status":"publish","type":"post","link":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/2007\/02\/12\/self-conscious-decoration\/","title":{"rendered":"Self-conscious Decoration"},"content":{"rendered":"

Variations on the Decorator Design Pattern in Ruby have already been discussed in<\/a> several<\/a> places<\/a>. For my special purpose, none of these approaches works.<\/p>\n

The common problem with a decorator based on delegation<\/a> is the lost sense of self. Method calls of the decorated object to itself are not routed through the decorator, therefore remain woefully undecorated.<\/p>\n

The Ruby idiom of aliasing and redefining methods, in effect adding around advice, is possible, when the decoration applies to all uses of the “core” class. It is not suitable when you need decorated as well as undecorated variants.<\/p>\n

There’s an almost classical: Just derive a subclass from the “core” class and add the decoration in there. Doing this explicitly is tedious, ugly, and multiplies classes semper necessitatem<\/em>. Luckily, for us and poor, overquoted Father Ockham, Ruby is a highly dynamic language where things are possible that users of other languages can only dream of (longingly or in nightmares, that’s quite a different issue).<\/p>\n

So, without further ado, here’s a simple demonstration of the technique.<\/p>\n

<\/p>\n

\r\nclass Core\r\n  def m1\r\n    puts \"Core#m1\"\r\n  end\r\n\r\n  def m2\r\n    puts \"Core#m2\"\r\n    m3\r\n  end\r\n\r\n  def m3\r\n    puts \"Core#m3\"\r\n  end\r\n\r\n  def m4\r\n    puts \"Core#m4\"\r\n  end\r\nend\r\n\r\nclass Decorator\r\n  class << self\r\n    def new(*args)\r\n      decorate(Core).new(*args)\r\n    end\r\n\r\n    private\r\n    def decorate(klass)\r\n      decorated_class = Class.new(klass)\r\n      decorated_class.send(:include, Decoration)\r\n      decorated_class\r\n    end\r\n  end\r\n\r\n  module Decoration\r\n    def m1\r\n      puts \"Decorator#m1\"\r\n      super\r\n    end\r\n\r\n    def m2\r\n      puts \"Decorator#m2\"\r\n      super\r\n    end\r\n    def m3\r\n      puts \"Decorator#m3\"\r\n      super\r\n    end\r\n  end\r\nend\r\n<\/pre>\n
<\/code><\/p>\n
With that under under our collective belt, here’s the case that motivated my attempt at self-conscious delegation. In a Rails application, I have several layers of FormBuilder<\/code>s. At the base, derived from ActionView::Helpers::FormBuilder<\/code> is a form builder that provides mechanisms<\/em>. For example for adding labels to input elements and for automatically displaying appropriate widgets for various association types. On top of that, I have two form builders that add layout<\/em> specifics; one for CSS-based layouts, one for table-based layouts. I still need a further layer for policy<\/em>: only show users what they are allowed to see and touch. This last policy layer is, of course, independent of layout (and vice versa!), therefore, short of full-fledged AOP, decoration was the way to go.<\/p>\n
<\/p>\n
\r\nclass DecoFormBuilder\r\n\r\n  class << self\r\n    def new(object_name, object, template, options, proc)\r\n      delegate_class = options.delete(:delegate_builder)\r\n      raise ArgumentError, 'No :delegate_builder given to DecoFormBuilder' unless delegate_class\r\n      decorate(delegate_class).new(object_name, object, template, options, proc)\r\n    end\r\n\r\n    private\r\n\r\n    def decorate(klass)\r\n      decorated = Class.new(klass)\r\n      decorated.send(:include, Decoration)\r\n      decorated\r\n    end\r\n  end\r\n\r\n  module Decoration\r\n    def initialize(object_name, object, template, option, proc)\r\n      super\r\n      # Do whatever initialization you need here\r\n    end\r\n\r\n    # Put the decorating methods here and don't forget to\r\n    # call super.\r\n\r\n  end\r\nend\r\n<\/pre>\n
<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"
Variations on the Decorator Design Pattern in Ruby have already been discussed in several places. For my special purpose, none of these approaches works. The common problem with a decorator based on delegation is the lost sense of self. Method … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,4],"tags":[],"class_list":["post-17","post","type-post","status-publish","format-standard","hentry","category-rails","category-ruby"],"_links":{"self":[{"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/posts\/17","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=17"}],"version-history":[{"count":1,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/posts\/17\/revisions"}],"predecessor-version":[{"id":146,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/posts\/17\/revisions\/146"}],"wp:attachment":[{"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=17"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=17"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.schuerig.de\/michael\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=17"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}