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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.