From: Robert Klemme Date: 2011-12-05T06:25:58+09:00 Subject: Re: Inverse Operation of Module#include On Sun, Dec 4, 2011 at 8:04 PM, Peter Vandenabeele wrote: > On Sun, Dec 4, 2011 at 7:23 PM, Robert Klemme wrote: > >> On Fri, Dec 2, 2011 at 7:28 PM, Peter Vandenabeele >> wrote: >> > On Fri, Dec 2, 2011 at 1:49 PM, Steve Klabnik > >wrote: >> > >> >> Abstract base classes are silly in Ruby; why bother with that >> >> inheritance? Just take advantage of duck typing. >> >> > I was under the impression that it does make sense to have an abstract >> > base class that has a number of generic methods and then derived classes: >> > * add some specific methods >> > * add some specific attributes >> > * override some of the inherited methods >> >> => Template method pattern > > > Thx for that pointer. I am still not clear what Steve exactly meant with > his comment. > > >> > I have a specific example I was just implementing with an abstract >> > base class for an "account" (think "bank account"). There are different >> > derived classes, e.g. for simple money, but also for credits. Certain >> > functions are generic (e.g. balance), but certain functions are specific >> > (e.g. put funds on the account will use decimals for "money", but only >> > accept integers for "credits"). I have put some demo code below. >> > >> > Very curious to hear how this design could be improved with duck typing. >> >> Not really duck typing, but this is how template method could look in this >> case ... > If I understand correctly the improvement in your version is that you only > override exactly that part that is different for the derived class vs. the > generic > class (the "ensure_proper_amount" validation). Nice, thanks. Correct. That's what template method pattern is about: you have a method which gives the overall structure and sub classes fill in only missing methods (which would be abstract in a language like Java). You're welcome! > With respect to the locking strategy you propose. I am actually reading and > writing the amount from an SQL database with ActiveRecord, from potentially > multiple parallel processes (multiple Rails processes from passenger, > potentially even on  different servers). Am I correct that this locking > strategy with > MonitorMixin would not be relevant (default Rails passenger set-up with > multiple processes, but no multi-threading inside a process). I believe a > different locking strategy would be required, e.g. acquiring a lock from the > database or from another source of locking that is shared between the > different processes (multiple processes per server and multiple servers). Yes, of course. Since there was no concrete hint I chose thread synchronization as a (hopefully) well known pattern. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/