Skip to Content.
Sympa Menu

gang-of-4-patterns - Re: [gang-of-4-patterns] Task Prioritization Patterns

gang-of-4-patterns AT lists.cs.illinois.edu

Subject: Design Patterns discussion

List archive

Re: [gang-of-4-patterns] Task Prioritization Patterns


Chronological Thread 
  • From: <sayan.mukherjee AT iflexsolutions.com>
  • To: <conradwt AT runbox.com>
  • Cc: <gang-of-4-patterns AT cs.uiuc.edu>
  • Subject: Re: [gang-of-4-patterns] Task Prioritization Patterns
  • Date: Tue, 11 May 2004 14:57:42 +0530
  • Importance: normal
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/gang-of-4-patterns/>
  • List-id: Design Patterns discussion <gang-of-4-patterns.cs.uiuc.edu>
  • Priority: normal

Hello Conrad,

One of the good patterns for handling changes triggered by other changes
is the Observer Pattern (Behavioural).
The second part of the problem can be elegantly handled by this pattern.
You can do something like this:

There will be objects belonging to 2 classes viz. TaskManager and
TaskPrioritySetter.

1. TaskManager will have methods to poll the time remaining for all
tasks unallocated tasks.
2. TaskManager is the "subject" and TaskPrioritySetter is the
"observer".
3. TaskManager will have a method called notify().
4. TaskPrioritySetter will have a method called update().
5. TaskManager will contain a reference to the TaskPrioritySetter
object, say objSetter (assuming
one observer).
6. There will be 2 paired functions attachObserver() and
detachObserver() which will maintain
the reference(s) of the observer(s) in the subject.
7. After every hr, TaskManager will call its notify() method which will
contain a call
to objSetter.update() (or loop through all the observers calling the
update() method of each).
8. The update() function will connect to the database and make the
necessary changes in
the priority values.
9. The call to notify() should be from a dedicated thread with a timer
object/mechanism whose only job will
be to wait. On expiry of the timer, the call to notify is made and it
goes back to sleep again.
Note: The method notify() may be asynchronous; i.e. you may design
for it not to wait for the update method
to return after priority value update on the DB.

Advantage: One major advantage is the decoupling of the notifier and the
triggered action. If in future you need
another set of actions of an altogether different nature, you can create
another observer class, say TaskX, and
implement the necessary actions in its update() method. Class
TaskManager need not be touched.


Please let me know whether I have understood your problem correctly.

With best regards,
Sayan



-----Original Message-----
From:
conradwt AT runbox.com

[mailto:conradwt AT runbox.com]

Sent: Saturday, May 08, 2004 3:58 AM
To:
gang-of-4-patterns AT cs.uiuc.edu
Subject: [gang-of-4-patterns] Task Prioritization Patterns

Hi, I have a problem dealing with task prioritization (i.e. allocating
tasks to agents that are stored in a database based a computed priority
value). The agents will initiate the retrieval of getting a task from
the database and they should get the one that has the highest computed
priority value based on the type of tasks that they can work on. Next,
this priority value can be change based on the time that a certain task
needs to be completed. For example, if a task is due in 4 hours that's
in the database (i.e. not assigned to an agent) and two hours have
passed, then it's priority will increase. This has a rippling effect
because as time changes on the hour boundary, the database must
recompute the task's priority value. Thus, I was wondering, are there
any patterns that would assist me in designing and developing a clean
solution?

Thanks in advance,

-Conrad




_______________________________________________
gang-of-4-patterns mailing list
gang-of-4-patterns AT cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns


DISCLAIMER:
This message contains privileged and confidential information and is intended
only for the individual named.If you are not the intended recipient you
should not disseminate,distribute,store,print, copy or deliver this
message.Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.E-mail
transmission cannot be guaranteed to be secure or error-free as information
could be intercepted,corrupted,lost,destroyed,arrive late or incomplete or
contain viruses.The sender therefore does not accept liability for any errors
or omissions in the contents of this message which arise as a result of
e-mail transmission. If verification is required please request a hard-copy
version.





Archive powered by MHonArc 2.6.16.

Top of Page