Re: Inverse Operation of Module#include

On Sun, Dec 4, 2011 at 7:23 PM, Robert Klemme <[e-mail]>wrote:

> On Fri, Dec 2, 2011 at 7:28 PM, Peter Vandenabeele
> <[e-mail]> wrote:
> > On Fri, Dec 2, 2011 at 1:49 PM, Steve Klabnik <[e-mail]
> >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
>
> class Account
>  def initialize
>    extend MonitorMixin
>     @balance = 0
>  end
>
>  def balance
>     synchronize do
>      @balance
>    end
>  end
>
>  def put(amount)
>    ensure_proper_amount(amount)
>
>    synchronize do
>      @balance += amount
>    end
>   end
>
> end
>
> class MoneyAccount < Account
>   def ensure_proper_amount(amount)
>     raise "you can only put decimal amounts in a MoneyAccount" unless
>       BigDecimal === amount
>  end
> end
>


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.

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).

Thanks,

Peter