Meilleure structure de données Ruby pour l'organisation de la NFL

Question

J'essaie d'organiser des équipes NFL dans des structures de données dans Ruby. Mon but est de savoir facilement que les Ravens de Baltimore sont l'AFC (conférence) et l'AFC North (division).

Je voudrais également voir quelles équipes sont dans l'AFC (16 d'entre elles) et quelles équipes sont dans l'AFC North (4 d'entre elles). En ce moment j'utilise des tableaux sur des tableaux mais je suis sûr qu'il y a une meilleure façon de le faire. Avec la façon dont mes données sont structurées en ce moment, je dois mettre nfl [0] [0] [0] pour imprimer Baltimore Ravens (le premier 0 est AFC/NFC, le deuxième 0 est la conférence et le troisième 0 est la division). Cela semble être trop compliqué.

Une aide ou un aperçu serait incroyable!

Answer 1

Ils devraient être des classes ayant des relations plutôt que d'essayer de tirer parti de la structures de données ruby ​​natives. Même si les classes ne font pas les choses, vous obtenez beaucoup de code sonore naturel hors des relations ferroviaires.

Je préfère dire:

team = Team.find_by_name("Ravens") 

que

team = nfl[0][0][0] 

Vous obtenez aussi potentiellement d'autres appels utiles pour presque gratuitement:

team = Team.find_by_city("Baltimore") # also gets you the ravens 

et quand vous voulez saisir toutes les équipes d'une division:

all_nfc_teams = Division.find_by_name("NFC").teams 

qui est beaucoup plus lisible que

all_nfc_teams = nfl[0][1] 

Je peux imaginer toutes sortes d'autres sémantique utiles, comme trouver toutes la semaine 4 jeux pour l'AFC, ou de commander une division des équipes par des victoires et des pertes . Vous pouvez définir des étendues sur les équipes qui vous permettraient de récupérer des collections d'équipes avec une sémantique très claire.

all_nfc_teams = Team.nfc 

Answer 2

"Le meilleur" est subjectif. Cela dépend aussi de la nature des entités organisationnelles.

Est-ce que les divisions et/ou les conférences font autre chose que détenir des équipes? Si oui, alors ils devraient être des classes.

Sinon hash sont probablement très bien, bien que je pourrais les résumer dans une classe de commodité, pour cacher les structures de hachage, l'accès équipe nommée, etc.