Hi Charles, I don't mean to knock OO concepts, Object Oriented design certainly has its advantages, but at times elegant OO design creates more complexity than it removes.
I recommend you consider using different classes for Client A and Client B. It is true that this will prevent the automatic reuse of any changes that you make to these classes in the future, but it will significantly reduce the complexity of extending the class in a manner that is consistent with the needs of both clients. Complexity is the enemy of all enterprise computing projects. Even if you are successful in engineering around this (by no means an impossible task) your deployment teams will be left with the difficulty of configuring a software system that was not quite designed for either of the systems it was intended to interact with. Clearly this solution is inelegant from an OO perspective. But it is very common for elegant OO design to be a poor decision from a BUSINESS perspective. I echo these same points with respect to the all inclusive schema option you mentioned. The all inclusive schema (one entity bean has all the fields needed by any client) may be inelegant, but it is a useful tool for managing complexity and should not be ruled out simply because inheritance is more elegant. Of the three approaches I mention here, inheritance would be my last choice (especially so, given that your development tool doesn't like it). JWS ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
