Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reservation polymorphism #2

Open
nhocki opened this issue Dec 13, 2012 · 0 comments
Open

Reservation polymorphism #2

nhocki opened this issue Dec 13, 2012 · 0 comments

Comments

@nhocki
Copy link
Member

nhocki commented Dec 13, 2012

As seen on Gist: https://gist.github.com/4280095


I have a small problem. I'm trying to build a ruby client for a remote lab system
called Weblab Deusto. The basic flow of running an experiment on a lab is simple,
you have a username/password that you use to login. Once logged in, you can
access a list of experiments, each of those having a name and a category that
combined form a unique identifier inside the lab system.

Having an experiment, you can reserve that experiment and here's where things
get a little bit messy. The reserve response from the server will have
a status attribute. Depending on the status of the reservation, you will get
some parameters. There are five different status for a reservation.

All the clients I've seen implement this by having 5 different classes, one for
each status. Then, depending on the response, they instantiate one of those. I
feel this to be a little messy but I have no idea on how to make this better.

The main reason I think this approach is messy is because, everytime I'm going
to use a reservation (for any purpose), I'd have to ask what kind of reservation
it is, since their public interface is different. Let's think about a reservation
that is currently on position 50 on the queue, and I want to check the new
position of it. The problem is that if the status has changed, the reservation
may have no possition (because it's already finished for example). This way, I
can't do something like:

reservation.update_status!.position

I would have to do something like:

reservation.update_status!.respond_to?(:position)

I've thought about having all the attributes (like position) in all the reservation
classes, and that way I will have the same interface on all the classes, but I
have no idea if this is even worse than the current approach in other clients.

Any help? Thanks!

nhocki added a commit that referenced this issue Jan 16, 2013
I'm still not 100% comfortable with this approach but for now I think we
can get something working and then think about something else. Otherwise
nothing will be accomplished.

Related to #2
nhocki added a commit that referenced this issue Jan 16, 2013
nhocki added a commit that referenced this issue Jan 16, 2013
nhocki added a commit that referenced this issue Jan 16, 2013
This is now getting ridiculous!
nhocki added a commit that referenced this issue Jan 16, 2013
nhocki added a commit that referenced this issue Jan 16, 2013
This is what I don't like. But for now, let's make it work and fix
tech debt in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant