Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For personal educational purposes I am making a site for a conference. One of the object that exist in a conference is a session, which has different states and in each state it has slightly different attributes:

  1. When submitted it has a speaker (User in the system), Title and abstract.
  2. When under review it has reviews and comments (in addition to the basic data)
  3. When accepted it has a defined time-slot but no reviewers anymore.

I feel that it is not the best thing to add a "status" attributes and start adding many if statements...
So I thought it would be better to have different classes for each state each with it's own validations and behaviors.

What do you think about this design? Do you have a better idea?

share|improve this question

2 Answers 2

Agreed that gnarly if statements and conditional ActiveRecord validations are not the answer.

It seems like your idea is to have several classes such as Submission, UnreviewedSubmission, and AcceptedSubmission. I think this is an improvement, but you might have issues linking data. If I want to view all unreviewed submissions, how will I do that? If I reviewed a submission and want to undo that, how can I reverse my approval and get that reviewers list back?

If you're OK with losing historical data, the approach above could work.

I'd also consider storing the initial Submission model and separately, an immutable list of state changes to it. For instance, a Review object could be created to signify that someone reviewed a submission. To figure out the state of a Submission, you'd find the original Submission object and then go through all the Review objects. There'd be a run-time performance penalty but you'd gain history tracking and clearer validations on state change.

share|improve this answer
    
Thank you for this, i am trying to solve the problem using a state machine, it seems there are several gems that help with that. When i am finished i will post my solution. –  Elad Mar 23 at 17:59
    
+10: the last paragraph nailed it. The performance penalty will be negligible for any practical system. Conference sessions are created through a lot of human effort and consequently are few in number. –  kevin cline Jun 27 at 15:09

I would say that this is one of those situations that could justify the use of Single Table Inheritance (STI). For the rails implementations see the API. The nice thing about using STI in this case would be that you store all the data in a single table, but are able to provide different 'windows' on it through the various child models. This way you keep the data of previous states readily available and also cover any data shared between states (you might need to know who reviewed an accepted submission, but that wouldn't matter anymore once it was scheduled).

Hope this helps,

Niels

PS if a few more pointers would be of use, just let me know! (Although that is probably more on-topic on Stack Overflow. If you repost your question there, let me know and I'll answer it there)

PPS concerning the option of adding bunches of if-statements: that is generally considered to be a 'code smell' and thus best avoided. See this answer on SO.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.