>>As an exercise, fire up the code references, and see where exactly are you calling the procedure. If it's in more places that you imagined, or a surprise in any way, try to see whether these places would otherwise benefit from having an instance of the BO at hand.
>>
>>Besides, if the BO is lightweight (i.e. instantiating it many times is cheap), you can replace any "getjobitems(" with "oBo=create('myBizObj')+chr(13)+chr(9)+"oBo.GetJobItems(" and then you could just forget the function and use the BO everywhere.
>
>
>So, you advocate that, for methods that are truly unique to each BO, the most ideal and pure BO architecture is to have the code in the BO, and do not allow a BO method to call an outside procedure to pass of the work?

Not an outside procedure that would do _its_ work. You may have general stuff that's used everywhere, like OpenTable(), GetFirstFridayInNovember() and such, which doesn't steal work from any bizobject, but if you have BizJob class, then any manipulation of a job goes there. You may only want to leave it as lightweight as possible, so its init() doesn't do much (maybe check whether it has the cursor if it needs one) and the instantiation is, well instantaneous. Then it costs you nothing to create it whenever you need it - and in doing so, you may find what else may this object do, and move more code into it.

It's a way to achieve a neat answer to the core question of OOP, "where does the code go". Which you're already trying to answer. It's not just "should a job related function go into BizJob", but "which other functions may need to go into BizJob", i.e. is there anything else that's doing its job. You're refactoring already, so think of a way to make it neat. Next time you revisit the code, you'll spend less time looking for the exact piece that does what you're looking for, because it would be where your logic expects it. Saves time and nerves.