Page 1 of 1

What would this design pattern be? (If any)

Posted: Sat Jan 06, 2007 9:27 pm
by Chris Corbyn
Say you have a system which schedules events. Now, it needs to know certain rules about when the events can be scheduled, if two can occur at the same time, what locations are available, if too many people are already attending an event etc etc so that it can schedule the event appropriately. These rules may change regularly and you don't want to hack your code apart every time a rule changes so you make something you use like this:

(What's it called?)

Code: Select all

<?php

$event = new Event("Some Conference");
$scheduler = new Event_Scheduler();
$scheduler->addRule(new Event_Scheduler_MaxCapacityRule(150));
$scheduler->addRule(new Event_Scheduler_TimeConstraintsRule("1300", "1530"));
$scheduler->addRule(new Event_Scheduler_MaxSimultaneousOccurencesRule(3));
$details = $scheduler->scheduleEvent($event);
I don't have any implementation details, I'm just thinking up an interface but wondered if there were any patterns I should check out first. Is this the strategy pattern? It feels a bit too less focused than the strategy for some reason because the rules could be anything if it's designed well.

Posted: Sat Jan 06, 2007 9:35 pm
by John Cartwright
I would certainly say it is the strategy pattern in it's essence.

More so the reason why I posted, I have developed something very similar and would like to compare notes as I have found many shortfalls to this exact implementation. I see alot of possibilities, although the many shortfalls have led me to considering dropping this philosophy completely.

Posted: Sat Jan 06, 2007 9:42 pm
by Chris Corbyn
Ok cool, I've always used the same algorithm, with relatively subtle changes for each observer in the strategy pattern (autoloader for example).

I'd compare notes.... if I had any :) Just thinking out loud as of now. Thinking of a way to interface with each rule so that it actually means something to the Scheduler seems a bit tricky since from where I'm sitting either:

a) The scheduler makes "proposals" then calls all the observers and asks for a boolean true. Repeat until successful.... aka Brute Force :P
b) The scheduler knows about a limited set of rules itself and therefore the rules are all just combinations of a small subset

I haven't thought about it for too long though, I might just start TDD'ing it and see where I get. Unless we come up with something here?

Off to bed now though... it's 3:40 here and I'm returning from a night out feeling a bit geeky that the first thing I did when I got in was jumped on the forum :lol:

EDIT | Errmm... observer == strategy. Apologies, it's late :roll:

Posted: Sun Jan 07, 2007 4:59 am
by timvw
I think that you can sell this to people as the strategy pattern.. Since the scheduler delegates the decision to rules i would go for option (a). The 'proposalmaker' would probably go in another class, and will be aware of the schedule and (some) rules...


-----------------------------------------------------------------------------------------------------------------------------------------------------------------
We have more or less the same system... But instead of hardcoding the rules they're loaded from the database...

scheduler(scheduler_id, classname)
scheduler_rules(scheduler_id, rule_id)
rules(rule_id, classname, valid_from, valid_to, strictness)

But overhere the rules also have a 'validity period'... and a 'strictness' filter: strict / overridable / warning. strict means that the rule is always valid, overridable will query the user if he wants to ignore potential problems, and warning simply gives the user a message telling that something isn't optimal...

Posted: Sun Jan 07, 2007 9:16 am
by Chris Corbyn
How about a cleaner way to improve the speed of a brute force. Rather than a boolean, we can have certain responses such as (in code of course) "Must be earlier", "Must be later", "Too many people", "Room not available".

But then you still face the problem with the arbitrary rule "Fred said he's having his hair cut at 10am Tuesday"... in which case you can fall back to the simple case of "Not possible at this time".

Brute force isn't an overly efficient way (no sarcasm intended) of working things out though :( But then again, that's pretty much the human way of doing it.