La réponse de Daniel est correcte, mais considérez: pourquoi une classe de bibliothèque fait-elle référence à une classe de modèle? Le code de bibliothèque ne doit pas connaître les classes de modèles réelles, bien qu'il puisse connaître l'interface qu'elles fournissent.
Autre considération: pourquoi la méthode #schedule
demande-t-elle la classe du modèle? Si une nouvelle classe de modèle, Spaceship
voulait fonctionner avec #schedule
, alors #schedule
devrait changer pour fonctionner avec elle. Ce n'est pas nécessaire.
A la place, en quoi les objets Aircraft
et les objets d'autres classes sont-ils traités par #schedule
? Pouvez-vous extraire cette différence dans une méthode qui lui est propre? Ensuite, vous pouvez déplacer ces implémentations dans chacune des classes du modèle, et décider laquelle est utilisée par le polymorphisme, et non par le branchement.
Par exemple, ce qui était:
def schedule(action, vehicle)
if vehicle.is_an?(Aircraft)
possible_days = case action
when "travel"
["Mon", "Wed", "Fri"]
when "repair"
["Sat", "Sun"]
end
possible_days.rand
elsif vehicle.is_a?(Spaceship)
possible_days = case action
when "travel"
["Sat", "Tue", "Thu"]
when "repair"
["Sun", "Mon"]
end
possible_days.rand
end
end
deviendrait:
def schedule(action, vehicle)
vehicle.days_action_can_be_performed(action).rand
end
class Aircraft
def days_action_can_be_performed(action)
possible_days = case action
when "travel"
["Mon", "Wed", "Fri"]
when "repair"
["Sat", "Sun"]
end
possible_days
end
end
class Spaceship
def days_action_can_be_performed(action)
possible_days = case action
when "travel"
["Sat", "Tue", "Thu"]
when "repair"
["Sun", "Mon"]
end
possible_days
end
end
Quand une nouvelle classe est ajoutée, il a juste besoin de mettre en œuvre #days_action_can_be_performed
, et il travaillera avec #schedule
.
Ah, merci beaucoup! Tu m'as indiqué dans la bonne direction: ça marche parfaitement bien dans le navigateur. Je ne l'ai pas encore essayé parce que je fais du TDD: ça casse en RSpec. Je vais modifier la question. –