On Sun, Dec 4, 2011 at 8:04 PM, Peter Vandenabeele
<peter / vandenabeele.com> wrote:
> On Sun, Dec 4, 2011 at 7:23 PM, Robert Klemme <shortcutter / googlemail.com=
>wrote:
>
>> On Fri, Dec 2, 2011 at 7:28 PM, Peter Vandenabeele
>> <peter / vandenabeele.com> wrote:
>> > On Fri, Dec 2, 2011 at 1:49 PM, Steve Klabnik <steve / steveklabnik.com
>> >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 class=
es:
>> > * add some specific methods
>> > * add some specific attributes
>> > * override some of the inherited methods
>>
>> =3D> 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 differen=
t
>> > derived classes, e.g. for simple money, but also for credits. Certain
>> > functions are generic (e.g. balance), but certain functions are specif=
ic
>> > (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 typin=
g.
>>
>> Not really duck typing, but this is how template method could look in th=
is
>> case

...

> If I understand correctly the improvement in your version is that you onl=
y
> override exactly that part that is different for the derived class vs. th=
e
> 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 a=
nd
> writing the amount from an SQL database with ActiveRecord, from potential=
ly
> multiple parallel processes (multiple Rails processes from passenger,
> potentially even on =A0different 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

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/