0

In the context of sports scheduling, I have a ViolationChecker class intialized with a Match, whose task is to check whether placing the match in a given time-slot produces a rule violation or not. An example of its usage would be:

checker = ViolationChecker(match)
match_fits_in_timeslot = checker.check(timeslot)

The main job of the scheduling process is finding a fitting time-slot for ervery match in the schedule, therefore, we will have a ViolationChecker for each one of these matches.

In the scheduling class, we would find something along these lines:

if checker.check(timeslot):
    match.timeslot = timeslot
    match.save()

Now, the decision I need to make is where should I store those ViolationChecker instances:

  • Should they be a member of the Match class? They would be accessed just like this: match.checker.
  • Or should they be stored in a Match-ViolationChecker dictionary in the Scheduler class? They would be accessed this way: violation_checkers[match].

Option A is much cleaner, while Option B is a bit awkward. However, it makes more sense that the responsibility of calling the checker lies in the Scheduler class, whose task is to, well, schedule, rather than calling it from a Match, which is just an entity and doesn't necessarily have anything to do with the scheduling process.

How is this scenario usually tackled? Should it be a member or should a dictionary be used?

2
  • Why do you need separate checker objects for each match? Instead of something like match.checker.check(timeslot), can't you use a simple function can_be_scheduled(match, timeslot) that handles all matches? – amon Jun 15 '17 at 13:04
  • 1
    I am going to store additional information in the checker object, such as what time-slots were rejected (as the process goes) and why. That's why I need to keep the match in there as well. – dabadaba Jun 15 '17 at 13:30
3

I would think that, typically, the violation checker would not be a member of the match class. As you stated, Match represents a cohesive entity that doesn't really have anything to do with the scheduling process. Checking for violations is not its responsibility, nor does it seem like a responsibility that it should have, at least not to me.

With that in mind, I would use your dictionary idea. Alternately you could also create an entirely new entity whose responsibility is to track those violation checker instances for your scheduler. Without knowing more about your code, one of those sounds like the best way to go. I'm not convinced that it would look less clean either, as it sounds like it would be cleaner from an organizational standpoint.

5
  • 1
    I am interested in your second paragraph. What other entity would work out here? Isn't that what ViolationChecker would be for? The idea is to move the responsibility of checking whether a match fits in a time-slot to a whole different component/class. I can give you more details of my architecture in a chat room if you wish – dabadaba Jun 15 '17 at 17:06
  • I just meant that, depending on the specifics of what you are doing, it might make sense at some point in the future to think about a separate entity that manages the instances of the violation checker. Like, for example, if you eventually found yourself needing to add more functionality to the dictionary of violation checkers - more than just a simple dictionary would provide – Langecrew Jun 15 '17 at 17:11
  • Insofar as I understand what you are doing at present, your idea of a dictionary should work just fine – Langecrew Jun 15 '17 at 17:13
  • yeah I get it, but it's not just a matter of "it does or it does not work" but "is it a good design?" or should I consider doing things differently? but if you think the dict approach is fine, so be it :) – dabadaba Jun 15 '17 at 17:14
  • For sure, I get what you mean. Yes, I personally do think it would be better design to use the dictionary, instead of putting the extra responsibility in the Match object. That said, sure, either would work. But in a design sense, I'd go with the dictionary. I hope this is all helpful :) – Langecrew Jun 15 '17 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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