0

I have a Flight class which represents a flight in a pilot's logbook. It is composed of the following attributes:

  • duration
  • landings
  • remarks

It also has an airport and time of both departure and arrival, which are related to my question.

I have though about modeling the the arrival and the departure as a Movement, which would be composed of the airport and the time. I would then derive a Departure and an Arrival class from the Movement, and have the Flight reference one of both.

Then I bumped into a discussion on Ruby's TrueClass and FalseClass (Why does Ruby have TrueClass and FalseClass instead of a single Boolean class?). The gist of it was that Ruby does not model true and false as a Boolean because they do not share any behavior and I believe the same goes for an arrival and a departure. They are exactly opposite even though they do share data.

Another option is that I simply embed the arrival and departure's data fields in the Flight. I find this awkward because that would mean that if you would traverse from the Airport model to the departures and arrivals (has_many :departures, has_many :arrivals) would yield a Flight model.

A third option I explored is creating separate Departure and Arrival models without inheriting from a Movement. However, since a Flight is required to have both and arrival and a departure, which are required to reference flight, we have created a nasty circular reference (which also plagues the first option, by the way).

How would I best model this relationship? Are there any alternatives I have failed to consider?

Community
  • 1
  • 1
Laurens
  • 2,078
  • 5
  • 29
  • 46
  • 1
    The primary thing to consider here is how you are going to be accessing and updating the data models. How is the information going to be used in each case, and so on. As you've indicated that this is a pilot's logbook application, what are the important things about the end points of a movement, and that should tell you how best to implement it. Reversing the relationship through Airports might make that particular set of accesses a little slower, but that might be okay if it an infrequent thing. I think you're on the right track with modeling behaviour rather than data. – tamouse Jan 11 '13 at 18:35

2 Answers2

1

Speaking from a UI developer perspective, this is what I'd start with.

I suspect you will often do two things -

1) display the flight in a list and include the departure and arrival information in the list item 2) sort the list by time of departure and arrival

These will be easier/faster to do if the attributes are on the flight. You'll avoid the joins. Since the information is required, no need to 'has_one'. You can always move them later in a migration if you need to. Keep it simpler until the use cases come up.

I think it will also be easier for you to make a has_many :arrivals (which are of type Flight) on the airport by simply looking at the Flight's arrival airport id.

Mark Swardstrom
  • 17,217
  • 6
  • 62
  • 70
  • Thanks for the insights. You are right that I will be displaying the flight in a list to show departure and arrival information and have decided to keep it all in the `Flight` model to avoid complicating it. – Laurens Jan 12 '13 at 09:27
1

If you want Arrival and Departure to share a lot of functionality, consider using an active support concern or an abstract parent class.

Inheritance:

class Movement < ActiveRecord::Base
  self.abstract_class = true
end

class Departure < Movement
end

Module:

http://www.fakingfantastic.com/2010/09/20/concerning-yourself-with-active-support-concern/

http://api.rubyonrails.org/classes/ActiveSupport/Concern.html

AJcodez
  • 31,780
  • 20
  • 84
  • 118
  • Thanks for the response! The main issue was that the departure and arrival share data, I felt that they were complete opposites in terms of behaviour, which is why I was reluctant to model it using inheritance. I have decided to keep it all in the `Flight` model for simplicity. – Laurens Jan 12 '13 at 09:29