From: Robert Klemme <bob.news@...>
Date: 2005-01-25T17:20:50+09:00
Subject: Re: "Duck Typing" or "No need for abstract classes"


"Edgardo Hames" <ehames@gmail.com> schrieb im Newsbeitrag
news:478c16ae0501241442501dc6e5@mail.gmail.com...
> Hi, you all.
>
> I'm working on a new small project where several network protocols are
> to be supported. I had an idea about how to implement it and it
> resembled something like this.
>
> class Protocol
>   abstract :login, :logout, :send, :receive
> end
>
> class MyProtocol < Protocol
>   def login
>     # does something useful
>   end
>   ... # so on
> end
>
> Then my network client would just call the methods of a Protocol
> object without caring about the actual classes that implement it (yes,
> you're right, I come from a static typing background). But then I read
> something (I don't remember where :( ) which said that agile languages
> don't need to implement so many patterns and I think I saw the light!
>
> I don't need a Protocol class, the network client should just call the
> methods of the protocol and duck typing should do all the magic. Am I
> right? Am I coming a little closer to walking the Ruby Way?
>
> Please, post a positive reply and you just may save me a couple of
> therapy sessions :P

:-)  You're compltely right.

Some additional musings: In your case I'd add a base class only if all
protocols share some common behavior or state.  This keeps redundancy low.

# example
class Protocol
  def cycle
    session = login

    begin
      yield session
    ensure
      logout
    end
  end

  def send_all(*a)
    a.each {|x| send x}
  end
end

Another reason might be that you have to plan for future extensions and
you want to have a place to put them.  Then you can justify an empty base
class because if you have lot's of protocols it might be tedious to add
the base class later.

Kind regards

    robert