Hi Gavin, Try not to think of OO design as an ER diagram with related methods bolted on to the tables - I did this once a long time ago, I'm sure there's an anti-pattern name for it, and it is not how OO apps get built.
Use objects to isolate code that may need to change independently of other code, not just to reflect the database. If we partition code by entities, all we are trying to achieve is that if we change the definition of "Bed" it won't affect the code attached to "Patient" (which doesn't quite sound right anyway) - it's not your main concern. It's more likely that Rules will change over time, or new events can occur, and we want to be able to add these without modifying existing code: "Open for extension, closed for modification" is the motto. As you're already noticing it doesn't make sense to put logic for a discharge event into a patient because it needs to know about other things that a patient doesn't need to know about - if you did start down this path I'm sure that very quickly you'd find every class needing to know about every other class to make things work, and nothing would be isolated from anything else - a hairball. Find some new homes for this logic outside your value objects/transfer objects/beans (i.e. patient, bed, room, hospital, doctor, bedpan) for instance off the top of my head "Rules", "Events", "Roles". An event happens. We fill in forms represented by value objects (signed out by = Dr. X) or use existing data (Dr. X has Role "uberdoctor") and build up an event (Discharge). We broadcast that the event is happening and various rules stick their hands up to have their say about whether it can happen (WhoCanApproveDischarge, NoDischargeLessThan24HoursAfterSurgery, ....) This all needs real analysis and the sort of stuff you're dealling with is particularly complex. But I'd strongly recommend leaving your value objects just for properties, not methods, and finding other homes for your code. Can I strongly recommend these books: http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124 http://www.amazon.com/Analysis-Patterns-Reusable-Object-Models/dp/0201895420 Be pragmatic - if OO isn't helping, DO NOT worry about it. (1) Make it work, and if you know something about the app is going to change over time, (2) try to minimise how much the rest of the code knows about it. That's all that matters. Cheers, Robin ROBIN HILLIARD Chief Technology Officer [email protected] RocketBoots Pty Ltd Level 11 189 Kent Street Sydney NSW 2001 Australia Phone +61 2 9323 2507 Facsimile +61 2 9323 2501 Mobile +61 418 414 341 www.rocketboots.com.au On 14/12/2010, at 9:54 PM, Gavin Beau Baumanis wrote: > Hi Everyone, > > I have an OOP question for those in the know. > We write a Patient Management System and have been steadily creating objects > and CFCs for all new work. > The time has come to do "something" with our patients. > > Normally I would have an object, and all relevantly related methods for that > object would be "housed" within the same object. > > The issue I have is - that just about everything relates to a patient in a > behaviour / code sense. > I can easily see the patient object groing to some obscene length because of > all the things you can do to a patient. > > Eg you can admit a patient. > discharge a patient > re-admit a patient etc. > > or illustrative purposes let's consider discharging a current patient. > There is a pre-defined set of steps that need to be done. > * Ensure that the user has an appropriate level of authorisation for THIS > process. > ** This is a method in a "permissions" sub-system that we have already > created. > ** Ensure THIS patient is valid to be discharged. > ** you cannot discharge a patient that is already discharged > ** you cannot discharge a referred patient that has not been admitted. > > * Provide a form to collect the relevant data required for the discharge > record. > ** Some of this information is stored in a dischargeinformation table > ** Some of this data is stored directly in the patient table - and would be a > property of the yet-to-be-created patient CFC. > > My question is; > Where does the business logic for this "kind of thing" go? > It's patient related so I figure it should go in the patient object. > But it's not completely operating on just the patent object. > the discharged information will not be part of the normal patient object . > > I look forward to some insight - and thanks as always! > > Gavin "Beau" Baumanis > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
