|
Joe Pluta wrote: > ... > The problem with applying OO to business applications is that it doesn't > work. As you point out, inheritance falls apart quickly when designing > business objects. Unfortunately, so does its alternative, composition. For > example, in the case I discussed, the MRP generation, there are perhaps a > dozen different flags with a hundred different states. If you program these > each using a separate class and use a hierarchy heavily dependent upon > composition, then you will be performing tests all throughout your > containing class to determine the appropriate actions. You will, in effect, > be reproducing all the procedural code except you will have added the > overhead of the object design. > ... Joe, sorry, but I have a *big* problem with your main contention that somehow business applications are too complex for OO languages, and yet a procedural language is just fine. The capabilities of the typical OO language are clearly much greater than procedural languages in many areas: Data structuring, interface definition, modularization, function libraries, etc, etc. To argue that a problem domain that is somehow too complex for OO can be handled more easily by a less capable language just goes against plain common sense, in my humble opinion. Hans
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.