Avoiding the God Class (Containment/Delegation or ??)

[Smithers]

I'm designing a Windows Forms application for a medical clinic that keeps
complete and comprehensive histories on its patients: histories of medical
conditions and facts, financial facts, psychosocial evaluations, etc. There
is a whole bunch of stuff they track about each patient.

I am tentatively planning on implementing something close to the MVP
pattern, with this "Person" class at the BOL. The "Person" class would be
akin to the MVP model class.

As the scope of the project has increased, it seems that the amount of
information the business wants to track about their People keeps increasing.
My initial thoughts are that the Person class would contain a bunch of
other/helper classes (mostly to contain/manage various collections of
"things a person has" - like medication history, appointments, etc).

So my question: If my Person class comes to contain a large number of other
classes (mostly to manage collections of "things about the person"), is that
fact, by itself, a red flag in terms of good OOP design? I ask because, even
though I have separated out a lot of functionality (per MVP), this "Person"
class is starting to smack of the "god class" antipattern - simply because
it contains so much data.

How would I better manage all these facts about People - in the BOL - than
to have one big Person [model] class?

FWIW: The forms (screens) the users will see all need to show some common
data about the patient (name, medical record number), and then
"form-specific" data, like "social worker notes" or "medication refill
requests" etc.

Thanks!

[Joanna Carter [TeamB]]

"Smithers" <[e-mail] écrit dans le message de news:
uT************* *@TK2MSFTNGP03. phx.gbl...

| How would I better manage all these facts about People - in the BOL - than
| to have one big Person [model] class?
|
| FWIW: The forms (screens) the users will see all need to show some common
| data about the patient (name, medical record number), and then
| "form-specific" data, like "social worker notes" or "medication refill
| requests" etc.

You have to be careful not to detach too much information, but the simplest
guidance is that, unless the Patient "owns" the information, it doesn't
belong in the Patient class.

Attributes like Name, Address, RecordNumber, etc, certainly belong in the
Patient, but most of the lists will belong outside. e.g. Appointment will
belong in an AppointmentBook class, Medication will belong in a Dispensary
class, etc.

This structure then also allows the modelling of the n-n relationships that
can occur in scenarios like the Dispensary class, where a Patient can have
multiple Medications and a Medication can be supplied to many Patients.

Classes like the AppointmentBook will have GetAppointments For(Patient)
method and GetAppointments For(Doctor, Date/Time) methods which will return a
list of Appointment objects, as well as a GetPatientsSeen On(Date) method
which will return a list of Patients, GetFrequencyFor (Patient), etc.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[=?Utf-8?B?Q2lhcmFuIE8nJycnRG9ubmVsbA==?=]

I agree with the below but would add that IMO it is good for the patient to
have an Appointments property which returns (probably cached) result of
AppointmentBook .GetAppointment sFor(Patient).
That not a GOD class as it isnt responsible for the information in the
AppointmentBook or Appointment classes, it can just serve them to you.

--
Ciaran O''''Donnell
http://wannabedeveloper.spaces.live.com
"Joanna Carter [TeamB]" wrote:

"Smithers" <[e-mail] écrit dans le message de news:
uT************* *@TK2MSFTNGP03. phx.gbl...

| How would I better manage all these facts about People - in the BOL - than
| to have one big Person [model] class?
|
| FWIW: The forms (screens) the users will see all need to show some common
| data about the patient (name, medical record number), and then
| "form-specific" data, like "social worker notes" or "medication refill
| requests" etc.

You have to be careful not to detach too much information, but the simplest
guidance is that, unless the Patient "owns" the information, it doesn't
belong in the Patient class.

Attributes like Name, Address, RecordNumber, etc, certainly belong in the
Patient, but most of the lists will belong outside. e.g. Appointment will
belong in an AppointmentBook class, Medication will belong in a Dispensary
class, etc.

This structure then also allows the modelling of the n-n relationships that
can occur in scenarios like the Dispensary class, where a Patient can have
multiple Medications and a Medication can be supplied to many Patients.

Classes like the AppointmentBook will have GetAppointments For(Patient)
method and GetAppointments For(Doctor, Date/Time) methods which will return a
list of Appointment objects, as well as a GetPatientsSeen On(Date) method
which will return a list of Patients, GetFrequencyFor (Patient), etc.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

"Ciaran O''''Donnell" <Ci************ @discussions.mi crosoft.coma écrit
dans le message de news:
E4************* *************** **...icrosof t.com...

|I agree with the below but would add that IMO it is good for the patient to
| have an Appointments property which returns (probably cached) result of
| AppointmentBook .GetAppointment sFor(Patient).
| That not a GOD class as it isnt responsible for the information in the
| AppointmentBook or Appointment classes, it can just serve them to you.

I come up against this a lot when consulting for companies whose systems
have gotten way too complicated to maintain or update :-)

OO design, was always and still is, meant to be about modelling the real
world rather than having to create some relational absraction. In the real
world, you would not ask a Patient for their list of Appointments; do you
know every appointment you have ever kept ?

Also adding a GetAppointments method to the Patient class implies that you
should be able to get a list of all appointments, not just with a medical
practice - solicitor, lunch, etc are also appointments.

Another consideration is that Patient is not necessarily the best class in
which to hold personal information like Name, Address, DoB, etc. What if a
Patient is also a Doctor or Nurse at a practice ? Do you duplicate that
personal information in the Doctor or Nurse class ?

Where there is a possibility of a person being (e.g.) a patient and a nurse,
then it is advisable to separate out a Role base class, from which roles
like Doctor, Nurse, Patient, Receptionist, etc can derive. Then you *will*
have a list of Role objects in the Person class.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer