Re: The next big thing?
- From: "Wayne Niddery [TeamB]" <wniddery@xxxxxxxxxxxxxx>
- Date: Mon, 24 Jul 2006 11:06:21 -0400
Jeremy McGee [BassettData] wrote:
After all, I don't have to create a TListBox or a TLabel: Delphi
includes that for me in its class library. So why should I have to
have a TPerson? Or a TCompany, an IAddress, or any of the other
standard object classes that 80% of business applications use.
Precisely because...
Now, I know that *my* interpretation of a customer might be different
from someone elses': for instance, it may be that I need a SIC code
attribute, and others don't. That's no big deal, I'll subclass.
.... practically every business or application is going to want or need any
number of such differences. You are going to have to create a subclass in
almost every case, so it doesn't really save you much if anything - you
*are* still effectively (re)creating TPerson again and again anyway. Beyond
perhaps name and birthdate, there's not much that can be tucked away in a
generic TPerson that will be *correct* for each different application -
address and other contact details vary widely across the globe and most
other requirements vary even more wildly. There's various ways of modelling
some of these requirements, whether it be sublclassing, modelling roles,
aggregating interfaces, but in each case, other classes, interfaces,
subclasses, and relationship constraints need to be designed to represent
the *entire* "TPerson" for any given problem domain.
Delphi did this very nicely for the UI and Windows internals. Can we
please have the same for distributed development?
A tool is not the same as the things that tool operates on. What can be
supplied is better and better methods to access and relate distributed data,
but a TPerson is not a tool, its the *target* of tools. Tools are much
easier to abstract and standardize even when they need to handle varying
data requirements, but data will always vary.
We've had the *technical* ability for many years already (since OO became
mainstream) to create "standard business objects" that can simply be
connected like lego bricks to create new applications (this has been a Holy
Grail for as many years) - but that goal is flawed because it ignores the
above - every business has different requirements and different ideas on
what a *correct* model is their business entities.
Such goals work to a reasonable degree in *specific* problem domains, for
example there are a few object-oriented accounting packages out there that
will work quite well in most cases, but this is because the *field of
accounting* is standardized sufficiently around the world to allow a set of
objects to abstract much of it. There is no such standardization possible
for TPerson, no standards that say it must have any specific set of
attributes or behaviour contraints or processing rules.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Nurture your mind with great thoughts. To believe in the heroic makes
heroes." ? Benjamin Disraeli
.
- Follow-Ups:
- Re: The next big thing?
- From: Peter Morris [Droopy eyes software]
- Re: The next big thing?
- References:
- The next big thing?
- From: Peter Morris [Droopy eyes software]
- Re: The next big thing?
- From: Jeremy McGee [BassettData]
- The next big thing?
- Prev by Date: Re: BDS2006 experts - which are useful?
- Next by Date: Delphi for .Net 3?
- Previous by thread: Re: The next big thing?
- Next by thread: Re: The next big thing?
- Index(es):
Relevant Pages
|