User:Paul Clark/Whiteboard

Whiteboard (for further developing Planned Ideas)

Two different ideas for structuring these classes. Obviously not finalised yet, I am leaning toward "Try No. Two" because when tasks are assigned, they need to be assigned to a network and a person, but the tasks shouldn't know to whom they have been assigned (IMO). So the class which assigns the tasks needs to know that a network is different from a person. (See also the next point below.)

Network as a composite

Now I am having issues deciding how to structure the three classes above. My issue with the composite design is that since the Network class has to hold at least all the un-assigned/claimed tasks, the assigner needs to know which Doer is a network (or does it, if the assigner just assigned the task to 'home, paul, josh', that would work.), and something would need to know which Doer was the network to find out which tasks were unclaimed too. So I am pretty sure the Composite pattern is out for this case.

Network as a ???

Here the Network gets passed a task list and assignee list. It adds the task to it's list of tasks, and list of unclaimed tasks if the assignee list is empty (eerrghh). It also assigns the task to the relevant people which are also contained within the Network. This is the easiest implementation (right now) and so the one I will start with, it may ot be the best though.

Network as a Chain

This also suffers from hiding the interface of Network.

Issues with this implementation include: 1) The Doers have to pass themselves to the Request as parameters, again as I have designated that the network should contain at least the unclaimed tasks, then 2) if a GUI say were to display a list of unclaimed tasks It would have to go through the chain casting or calling lots of no-ops until it found all the Networks, 3) else it would have to do some kind of call back request, which would have to know about the implementation of both Network and the class it was to call back too.