Re: polymorphism (was: Poly Couples)

Davor wrote:
topmind wrote:
Well, I couldn't give an exact boundary anymore than one can give an
exact boundary for "country music". However, it tends to do with

Of course you can't - I did not ask for that either - I just wanted
that you say a bit more precisely what you are referring to...

billing, inventory, reports (formal and ad-hoc), tracking, commisions,
marketing, etc.

OK, so what they typically call business/enterprise software... Good.

perfect) coded example because it needs typical CRUD (edit screens &
reports) of biz apps, and everybody who has gone to college is familiar
with the concepts. Thus, there is little need to explain the domain.

OK, but this is not really "business software"... This is a general
description of a system consisting of

UI
data storage
operations to create, read, update, and destroy data

Even my basic text editor is such a system, but is not considered
"business software".


This is why I use the term "custom business software". They don't come
in a box.

I'm sure there are off-the-shelf solutions for each of above, but it's
not a problem - I guess I can see what you mean... You are referring to
heavy data management applications - the ones typically dealt with a
database solution :-). In particular the ones where heavy relational
exploration of data is needed - the ones best suited for relational
processing.

Most of such applications are built as a combination of

*procedural and relational processing*

So, I guess you would like someone to show you if a solution with

*OO and relational processing*

is better than above?

If yes, that boils down in my mind to showing if OO is better than
procedural... Right?

Also, for any meaningful comparison we should quantify what "better"
means, in order to proceed with any meaningful comparison....

I am just saying that there is a void of OO examples for custom
business software. The examples one finds in the OO training material
do not reflect the custom biz apps that I deal with. They are obsessed
with device-drivers and swappability, something I don't see a big need
for.

The proportion of procedural code is relatively small as compared to
relational code in the applications you are talking about.

Not necessarily. It depends on the coder. SQL is often not as
expressive as I would like, so I shift that to procedural for some
parts. (SQL's faults are generally language-specific, not the fault of
relational in general. SQL is kind of long in the tooth.)

Also, the
complexity of procedural code in such applications is not high, and all
complex processing is done in some relational query language...

I don't think I would agree with that. If it wasn't complex, there
would be very little code (if factored properly). The complexity is
often implementing seemingly arbitrary business rules created by
marketers, managers, and law makers. One has to translate goofy
requests into code.

So in
such applications I would not even bother writing OO code... If it
happened that procedural part of such application is
larger/more-repetitive/with-a-lot-of-smaller-variations-depending-on-case/etc.,
I would probably include some of the OO structuring mechanisms, used a
bit of polymorphism, and a bit of extension to make the procedural part
a bit better organized... So, I don't see a big deal with all this...

Lots of repeating case statements is generally a sign that a new table
is required.


For example, OO'ers keep harping on, "what if you want to replace your
database with flat files or a different RDBMS vendor?" That is not a

that is not an OO decision - doing things like that involves a lot of
architectural decisions...

common need. I am not going to waste code on trying to make generic
wrappers (if even possible) unless there is an up-front known need for
such. Future discounting (similar to ROI curves) finance concepts are
also against it.

requirements/architecture/project management issues - not OO or
relational or structured etc. issues...

Again, I don't see what a big deal is... For applications that
requirements tell me that I'll need a significant amount of relational
processing, of course I'm gonna make an architectural decision to use
relational database (unless having requirements that constrain me from
making such a decision), and if the procedural part of such an
application is relatively simple and small (which typically is), I
couldn't care less if I do it in using structured programming or OOP
(would chose based on a number of project management issues such as
developer's familiarity, what we already have in terms of
infrastructure, etc.)

Again, I would not necessarily characterize the procedural part as
"small". However, you are correct in a way because the database is (or
should be) the key. The database is like The Nile and the procedural
code is like villages along the shore.


Of course, if I misunderstood, and you were discussing all this based
on the fact that someone told you that you should substitute what you
would typically handle using relational processing with typical OOP
that's completely another story... But in that case, it is still not
the issue of OOP, but rather the question of substituting relational
processing with procedural processing, since in most cases when you say
OOP, it's still procedural processing at the core with a number of
features for structuring and reusing that procedural code, but at the
bottom of the line it comes to the comparison of relational to
procedural processing for a task where relational have significant
advantages.

A given set of OOP code would generally produce some relational code
and some procedural code if de-OO'ed. The biggest difference is that
anything resembling a noun taxonomy or noun classification system is
usually moved to the database and what is left to procedural is
behavioral decomposition. OOP tends to mix noun classification and
behavioral issues together in the same code, often artificially forcing
the marriage IMO.


Davor

-T-

.

Relevant Pages

  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... The proportion of procedural code is relatively small as compared to ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)
  • Re: Decouple SQL queries from class in OOP design
    ... > Of course there are existing applications that uses many different ... > architectures and still provides measurable business value. ... > should access every database directly. ... by the database, but the schema changes. ...
    (comp.object)
  • Re: Newbie object design questions
    ... >> Business Entity from the actual structure of the database and the ... bunch of applications blow up because they ... database in the same way that the business thinks of them. ... tables storing information about one business entity). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [Info-Ingres] String Manipulations
    ... and business rule enforcement. ... ensure that all the applications conform to the same conceptual model by ... testing them with reference to the model in the database. ... and that data *has* to conform to the conceptual model, ...
    (comp.databases.ingres)
  • Re: Iwould like to build a data base in Access
    ... functions you wanted to combine in one database. ... The templates provided by Microsoft are for generating rather simple, ... application to run an entire business. ... free samples or examples create applications rather than templates. ...
    (microsoft.public.access.gettingstarted)