Re: Template Method Pattern (GoF) without abstract methods in Ruby
Austin Ziegler <[email protected]>
| Newsgroups | gmane.comp.lang.ruby.general |
|---|---|
| Message-ID | <CAJ4ekQt-WO8_eBKQ04SAFgAtNghS0upnzF4C226mr+nK7b8pMA@mail.gmail.com> |
On Fri, Jan 11, 2019 at 4:08 AM Michael Schwarze <[email protected]> wrote: > Hi Austin, > > Thanks; I’m from a different programming language background and curious > whether there is kind of a 'pattern of implementation‘ for implementing the > Template Method Pattern in Ruby. My 'research‘ so far brought > contra-dictionary results: the book on design patterns in Ruby saying not > to use 'abstract‘ methods, but showing them in the respective examples and > the examples found on the web |1, 2, 3] showing these 'abstract‘ methods in > Ruby, too. > But that’s my point. If you’re trying to implement the `Template Method Pattern`, you’re trying to use GoF as a recipe book. This is a mistake and will only hinder your learning of Ruby. What problem are you actually trying to solve? I have yet to see a place where I have needed to implement most of the GoF patterns in Ruby—some of these are because the language provides features that supplant the need for such a pattern. In Ruby, you quite *literally* don’t need abstract methods. class Processor def process step1 step2 step3 finalize end private def finalize # finalize the process here end end class Foo < Processor private def step1; end def step2; end def step3; end end If I do Processor.new.process, I will get a NoMethodError because I have no implementation of `step1`, `step2`, or `step3`. If I do `Foo.new.process`, it works. You don’t need abstract methods in Ruby because the methods don’t have to exist during compilation, because there’s no compilation phase or static method resolution. I don’t try to solve the template method pattern because I’ve been developing long enough that I recognize that pattern descriptions are forensic descriptions of common implementation patterns—often not necessary in languages with advanced and/or functional features (they have *different* patterns that can be forensically described) and not an instruction manual or language comparison tool. -a -- Austin Ziegler • [email protected] • [email protected] http://www.halostatue.ca/ • http://twitter.com/halostatue Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>