I am trying to implement a library that provides an unified way to
communicate to a server which is changing its API calls from version to
version. I plan to implement it that way:
connect.rb:
class Connect
def self.getConn(params)
case params[:version]
when ‘4.0’ then return Connect4.new(params)
when ‘5.0’ then return Connect5.new(params)
else ‘Version not supported.’
end
end
end
class Connect4
def initialize(params)
# Code for v4.
end
end
class Connect5
def initialize(params)
# Code for v5.
end
end
test.rb:
require ‘connect’
conn = Connect.getConn(:version => ‘4.0’)
puts conn
I think it would work, but i’m still new to ruby and there might be
issues i’m not considering. Is there any best practice to handle these
kind of ‘challenge’?
class Connect5
def initialize(params)
# Code for v5.
end
end
One of the advantages of object orientation is inheritance - ideal in
your case. I would do something like:
class Connect
def Connect::get_conn(params)
case params[:version]
when ‘4.0’
return Connect4::new(params)
when ‘5.0’
return Connect5::new(params)
end
end
raise “Version #{params[:version]} not supported.”
end
def generic_func
…
end
end
class Connect4 < Connect
def initialize(params)
# Code for v4.
end
def v4_specific_func
…
end
end
class Connect5 < Connect
def initialize(params)
# Code for v5.
end
def v5_specific_func
…
end
def generic_func
# overloads generic one
end
end
The advantage is that instances of both Connect4 and Connect5 also
respond to methods defined in Connect. You can thus neatly divide
between things that are unique of each version, and things that are
common among versions.
As you don’t mentioned anything else i assume there is nothing wrong
with my approach in general?
Ruby has inherited from Perl the aspect of providing many many ways to
obtain the same result. Each person develops his/her
ideosyncrasies. For me, this is very true. For example, I would never
leave out the brackets from the list of parameters of a method (for
matters of readability).
What I can say is that your proposed solution is quite similar to what
I would come up with, but I guess many more options could be
invented. I suggest that, especially at the beginning, you focus on 1)
does it work?, 2) do I have to wait until next week for my results?,
3) do I understand reasonably well what is taking place?, and 4) does
the code look nice? For me, this last element is the most important
