>>>>>
>>>>>I think what is/was bugging me is that in my VFP framework I would have done this at a level higher than the BO. I use a BOManager that coordinates all the separate BOs and calls the various bits in order to do the calculation.
>>>>
>>>>Like a watch, your application is already a container for the parts. In a watch, one cog does not instantiate another cog. In the virtual world of software, that is possible, but slow. In a real watch, both cogs already exist and are linked at all times while the watch exists physically - runtime. Instantiate both and have them communicate. Your CalcPremium method in the PolicyBO just calls the CalcPremium method of the PremiumRateBO and does anything further it needs to do. It is the contract between the two objects.
>>>
>>>
>>>I sure wish in the end I understood which way you were leaning on this topic. Are you suggesting he should not instantiate another business object from the Policy Business object? One option would be to have another object say a PolicyManager object that would instantiate both to coordinate the work and return the results, but it sounded to me like the actual work being returned belong to the Policy business object. I see no reason why it shouldn't just go get any additional info it might need to accommodate that work effort. It shouldn't probably return information other than Policy information however.
>>>Your thoughts?
>>>Tim
>>
>>It was clear in my head anyways. I would have the application or form instantiate both objects - no real need for a manager object unless you want to make a container for these two objects and subclass them all together as a composite.
>>
>>The Policy object has a method called CalcPremium which calls upon an already existing PremiumRate object. They collaborate as peers, not by one instantiating the other like a mother does her child. That instantiation process takes 9 months! :)
>>
>>Its OOP, use real objects to visualize the relationships. :)
>
>If getting data from the PremiumRate biz obj in order to supply that to the Policy object is a lot like putting business logic in the UI. That is something I make every attempt to not do. What if this process is something to be used from a different UI?
>I think I am with Frank and Bob on this one to have an intermediary class that does the Policy calculation work and can create whatever business objects it needs to get the job done. I would put that class in my business layer so it could be re-used. It it was an incidental retrieval or not many of these, I see no reason not to just let one business object call the other.
>Just my opinion however.
>Tim

I don't believe in opinion. It is all based on evidence. Human memory is faulty and so the evidence that is used to formulate responses is not reliable, which leads to mistakes, misinterpretation etc.

You were originally suggesting having one business object instantiate another. Where was the first business object instantiated. Why can the second business object not be instantiated in that same place and then the two collaborate? If there was no need for a container object for the first one, there should be no need of a container object for more than one. If there is a possibility for more than one business object and only then is a container required, then use the container for even one object. Nice, consistent and repeatable construction technique.