> > 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.
I tend to agree. This has always been the major drawback of white-box reuse, inheritance, in OO enabled languages, especially whenever the "owner" or coder that maintains the class changes. > 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. > Well, from my experience, I don't find it either that common nor I would blame OO for it: it has more to do with the tools at hand (including the language and other constraints such as the EJB spec). Clearly, in a strictly business sense, if performance is not paramount(not a prime requirement) and the budget isn't that big, a more maintainable solution wins(better value/lesser TCO). IMHO, you should take the same pragmatic approach you use in discarding OO to embrace it when it makes sense(and I think by the way you write, you think this way as well). > 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). > And here again I wonder, if building a solution hacking your way around not the platform nor the requirements but the development tools makes any sense at all. I'm afraid I'm not familiar with VAJ as an EJB IDE, but I wonder if you will be able to continue using the same codebase in VAJ 4... And VAJ 5? Yes, I know VAJ 5 is not out there *yet*, but the choice of trusting a tool with a large portion of the code that will be executed at the cost of possibly restraining your IDE choice in the future seems dangerous to me. I've had to work with legacy OS, RDBMS, languages and app servers and even IDE choice and I just don't think it's a good idea. I'd rather code EVERYTHING myself to keep at least the choice of switching IDEs open for the future. IMHO, it seems like a flawed set of options. Many times we will have to work against legacy code, but producing legacy code right from the start seems like a very bad approach. I think containment provides a clean way of implementing component-oriented inheritance until the spec includes mechanisms oriented to simplify such tasks. My 2c, =========================================================================== 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".
