use a class object for this?

[pietlinden]

I have a database that works fine... I was just trying to make it a
bit more intuitive to use.

Basic structure:

CaseManager---(1,M)---Caseworker---(1,M)---Case---(1,M)---Paperwork

Rules:
Each caseworker may have no more than 10 open cases at a time.
Opening a new case "spawns" a series of due dates for paperwork (based
on a couple of dates. Joint Visit Date and Admit Date... these work
already).
Closing a case requires the scheduling of another joint visit and some
specialized paperwork.
Transferring a case to another social worker may only be allocated to
a caseworker with fewer than 10 cases (like original assignment).

Assigning a new case - get the caseworker with the fewest open cases
and in case of a tie, the first one with the oldest last case
assignment.

So I was thinking of something like:

iMAXCASES = 10 (just a named constant so that I can set the max # of
cases to determine if a social worker can accept another case).

clsSocialWorker
..FirstName
..LastName
..Caseload (a number)
..LastCaseAssignment(a date)
openCases (collection?)

clsCase
..OpenDate
..AssignedToSocialWorker
Methods:
OpenCase (create paperwork) '--once a case is opened, you can't reopen
it unless it's closed first...
ExtendCase(create paperwork) '--only applies to open cases
CloseCase (create paperwork) '--only applies to open cases
TransferCase (can only assign to SW with less than iMAXCASES)

"Paperwork" would be a collection "belonging to" clsCase.

Is this a sane approach or just a waste of time? (well, other than
learning to use classes...) The screwy logic it would encapsulate are
scheduling rules and assign/deassignment rules for new/transferred
cases. And then I could just encapsulate all the rules there.

Useful non-public properties...
..CaseLoad (just get a count from the DB of open cases, so use a totals
query and loop through the records?)
LastAssignDate (from another query).

It's not nearly as complicated as Albert's sample from the Rides
(http://members.shaw.ca/AlbertKallal/Articles/WhyClass.html)
application, but it's a manageable database that I could at least
learn this on... any ideas?

Thanks,
Pieter

 

[Albert D. Kallal]

Hum, you laid out your problem very nice...good for you!!

clsSocialWorker
.FirstName
.LastName
.Caseload (a number)
.LastCaseAssignment(a date)
openCases (collection?)

The one "key" concept I re-interned in my example was that you really only
need the class object when you writing code that deals with the data. So,
pop question:

Do you really have a lot of code that deals with the Social worker? Do
you find yourself writing recordset and procedural code to grab and
manipulate the above information IN CODE a lot? If yes, then a class object
makes sense.

However, if the above information is easily edited on a form (and perhaps a
sub-form displaying the open cases), then you not receive any benefit from
creating the above object.

TransferCase (can only assign to SW with less than iMAXCASES)

True,but the above assign might just a simple combo box that lets you choose
the sw on a form. Remember, we making the class object to force us to write
more code, but just more easily deal with a bunch of complex code in a very
easy to use object.

So, keep in mind those objects ONLY really help you when you have

data + lots of code

The screwy logic it would encapsulate are
scheduling rules and assign/deassignment rules for new/transferred
cases. And then I could just encapsulate all the rules there.

it's a manageable database that I could at least
learn this on... any ideas?

Well, you certainly do a great job of laying this stuff out and defining the
problem. (In fact, that skill of yours is likely more valuable then your
coding skills!!!).

Sure, if the code you have to write needs to constantly manipulate "all of
this" information as one single unit, then yes, it makes sense. So, for
editing of data, the object don't help, but when your writing code to deal
with the information, then it helps.

 

[pietlinden]

Hum, you laid out your problem very nice...good for you!!


The one "key" concept I re-interned in my example was that you really only
need the class object when you writing code that deals with the data. So,
pop question:

Do you really have a lot of code that deals with the Social worker? Do
you find yourself writing recordset and procedural code to grab and
manipulate the above information IN CODE a lot? If yes, then a class object
makes sense.

However, if the above information is easily edited on a form (and perhaps a
sub-form displaying the open cases), then you not receive any benefit from
creating the above object.


True,but the above assign might just a simple combo box that lets you choose
the sw on a form. Remember, we making the class object to force us to write
more code, but just more easily deal with a bunch of complex code in a very
easy to use object.

So, keep in mind those objects ONLY really help you when you have

data + lots of code


Well, you certainly do a great job of laying this stuff out and defining the
problem. (In fact, that skill of yours is likely more valuable then your
coding skills!!!).

Sure, if the code you have to write needs to constantly manipulate "all of
this" information as one single unit, then yes, it makes sense. So, for
editing of data, the object don't help, but when your writing code to deal
with the information, then it helps.

Okay... I guess I could use a combobox to choose the socialworkers I
could transfer a case to. (just limit the list using a combobox with
a totals query). Assignment... I could order the list in order of
"oldest case", so the first/default choice could be the social worker
with the lightest caseload, and those that are "booked" don't appear.

Case status... Open/Active, closed... etc. Just disable the edit of
the closed/inactive records in the On Current event of the form. As
for the paperwork... it's just part of the SocialWorker---(1,M)---
Case---(1,M)---Paperwork hierarchy... no big deal.

Okay, thanks for listening... and for the feedback. I used to do
software support, so I found that a complete but succint description
of the problem takes you at least half way to the solution.... (hard
to solve a problem you can't describe!).

Thanks Albert,
Pieter

 

[Albert D. Kallal]

Remember, we making the class object to force us to write
more code, but just more easily deal with a bunch of complex code in a very
easy to use object.

should read:

Remember, we NOT making the class object to force us to write
more code, but just more easily deal with a bunch of complex code in a very
easy to use object.