-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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
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
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 canaccess 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 thingsget a little bit messy. The
reserve
response from the server will havea
status
attribute. Depending on the status of the reservation, you will getsome 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!
The text was updated successfully, but these errors were encountered: