S
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!
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!