>
>> 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
···
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:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/