HI Mark / Chris, Thanks for the reply.
I suppose my dilemma is that I can't really think of anything other than the patient that I can attribute this task too. So in this "grey area" do I create a separate a separate object? That seems the most sensible, but... I just thought I would check. Because I can see a few of these popping up in our application. Whereby it's more of a process - as opposed to a task that any "single" object does. * Sure a user performs this task - but it isn't about the user. * It's actually for the patient that the discharge occurs, but as pointed out - if I continue down that path, I am going to have one massive patient object that needs to be created / destroyed all the time. Putting it in a "hospital / Hospice" object is an interesting idea but you have; * Patient Admissions * Patient Discharges * the Patient's Care teams * the Patient's Physical locations And pretty soon you're back to where you started wondering whether or not this should be in the patient object - after all patient is the NOUN in all of those. If I was doing a Fusebox application, I would have simply had a separate view file for the "discharge" and some "specific" files that "just" did the usiness rule / form processing for discharges. This is what I am leaning towards. This is what makes the most sense to me. Just create "purpose specific" objects patientDischarge, patientDeath, In IRC, Mark Mandel told me that I need to have a little more confidence / faith in myself. Which is fine in theory. I am however quite new to actually using OOP - as opposed to just "knowing / reading" about it.. I'd just like to make sure that I don't develop a habit that isn't considered a good practice. Gavin "Beau" Baumanis On 14/12/2010, at 11:10 PM, Chris Velevitch wrote: > I would not "house" all relevantly related methods for that object in it. > > Your example of "patient admissions" is a separate object and the > business of patient admissions is the sole responsibility of that > other object. > > If take your line of reasoning to it end, you'll end up including > things like which ward(s), the bed(s) in the ward, their GP, attending > physicians, attending nurses, surgeons who operated on them, vital > signs, ordered tests, test results, x-rays, MRIs, sonograms, etc. > > Patients move through hospitals, hospitals don't move through > patients. Besides, all this information can be found in their medical > record and that's a separate set of objects which refers to the > patient object. > > Keep your objects as simple as possible, but no simpler. > > > Chris > -- > Chris Velevitch > Manager - Adobe Platform Users Group, Sydney > m: 0415 469 095 > www.apugs.org.au > > Adobe Platform Users Group, Sydney > Topic: Making Sense of Mobile > Date: 29th November 6pm for 6:30 start > Details and RSVP on > http://apugs.groups.adobe.com/index.cfm?event=post.display&postid=32492 > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
