From: "Jesús Gabriel y Galán" <jgabrielygalan@...>
Date: 2011-04-06T15:53:15+09:00
Subject: Re: Seeking advice

On Tue, Apr 5, 2011 at 8:30 PM, Alex Rothbard <alex323@gmail.com> wrote:
> The factory design pattern is sort of what I want, but not exactly.
> Remember that there are three different classes (services) that need to
> take advantage of a transport. The library is broken down like this:
>
> There is a high level class that represents a user's overall account.
> The user uses this class only. This account class needs to access three
> different "services" (classes): the grid, the archive, and the
> transaction service. All three services need to communicate with the
> remote server using a transport.
>
> In the example above, the transport is providing methods for accessing
> the grid, but I am thinking of it in another way: the
> grid/archive/transaction classes should provide methods which correspond
> to the API on the remote server, and those classes then use the selected
> transport to send it across.
>
> In short, I have a server library which offers up three sets of APIs
> (one for each service), and I want to be able to allow the end user to
> easily choose which transport the client library uses when accessing
> these services.

Then something like:

class Grid
  TRANSPORTS = {:json => JsonTransport, :thrift => ThriftTransport}

  def initialize transport, params
    @transport = TRANSPORTS[transport]
    # ... initialize the transport with params if required or whatever
  end

  def method_xxx param1, param2
    @transport.call_remote_method(:xxx, param1, param2) # the
transport defines how to call remote methods, I guess
  end
end

grid = Grid.new :json, {:url => "http://my.json.service"}
grid.method_xxx ("a", "b")

If you don't want the client to know about transport params, you can
hide the configuration inside the Grid class, or read it from a file
or something.

Jesus.