From: Maurice O'Prey
I don't really know what point it is you are making,
but it seems to me you are promoting the use of
business objects.
Yes and No. How's that for a politically correct answer?
A "business object" may mean something quite different to a developer who is using an OO language within an OO runtime environment, than to one who is using a procedural language with traditional top-down, left-right, program flow. Since I generally work in the latter, we may have some difficulty understanding one another.
Notwithstanding, in the event that certain code or data needs to be shared and adapted across multiple contexts, then we'll likely agree that it should be encapsulated and maintained as a separate unit, and expose a common interface, applicable to every context where the interface is needed.
I don't see Customers, or Orders, or Order Items, or Products, or Users as "objects". I generally see them as "records", which may be passed in part (or whole), by value (or reference) to any number of procedures which may be shared in number of contexts for further processing. The coupling between data and methods may be loose. I prefer that kind of flexibility. But an OO programmer may envision tighter coupling between data and methods. And that may depend a lot on the individual you're discussing with. If an OO programmer ever advocates something like extending a "person" object to "employee" or "customer" objects, then I'd probably need to bow out of the discussion.
Personally I fully advocate their use (and agree with Walden,
disagree with Joe).
It's hard for me to disagree with either. They both make valid points. Joe was pointing out some trade-offs between exposing a simplified interface, vs. degradation in performance. While Walden pointed to a valid case for using a business object.
Nathan.
midrange.com
