Re: Why use relational tables in OO (please just take a look inside)

From: Arkadiy Vertleyb (vertleyb_at_hotmail.com)
Date: 03/17/04 

Date: 17 Mar 2004 12:40:38 -0800

"H. S. Lahman" <h.lahman@verizon.net> wrote

> I get the impression that you learned your OO from OOPL applications.
> B-) Unfortunately that's a good way to pick up bad habits because the
> OOPLs make substantial compromises with the Turing/von Neumann
> computational models. The proper construction of OO applications lies
> largely in the methodological approach one takes to OOA/D.

OK, I see we have fundamental differences here. I just refuse to
recognize the difference between analisys/design on one hand and
programming on the other. I believe that all three is a part of the
same thing that should be called programming. Just like this OOA/D/P
= OOP.

> Which? That I can provide such a library? That my "by hand" code will
> be just as maintainable?

Latter.

> In the OO case the goal is to provide long-term maintainability in the
> face of volatile requirements _without attempting to anticipate specific
> changes_. As soon as one starts making paradigm exceptions for specific
> situations, one must make assumptions about what sorts of changes may
> occur in the future. One is better off shooting at targets that aren't
> moving.

Every paradigm has it's limitations, and OO is not an exception. You
can achieve only so much with OO. You use RDBMSs for persistence,
right? You are bad -- this is not OO-correct. Why don't you stop it
and go with object databases? There are also other areas where OO
doesn't shine. Such cases lead to pretty ugly patterns such as
"visitor".

I like OO because it allows me to structure my code in more elegant
way. But if, for the sake of OO correctness, I have to maintain
duplicated instances of the same pointer in many places, by hand,
risking inconsistency in my data, I am sorry, I am not bying such OO.

For example you can have a set of recently hired employees (last year)
and a set of not so recently hired employees (last two years). The
second set should always contains the first one. Who will be ensuring
this invariant? And I am even letting alone the fact, that, before
fetching employees from this set, you always have to verify the
current date (because sets change not only as employees added, but
also with the time). Kind of ugly, don't you think?

Your statement that one should never use anything but OO looks to me
like one should always work with a hammer, but never with a saw.

My favorite language is C++, and it is multi-paradigm. If I use only
it's OO capabilities, I am not using half of it. C++ can be used as
OO language, procedural language, it also has static polymorphism.
There is even functional library for C++. We are just adding the
relational dimension to it.

> The biggest single problem in OO development today is the conversion of
> procedural developers. Many of them looked at things like procedural
> message passing in the OOPLs and believed they could overlay familiar
> procedural SA/SD construction paradigms on OO development. The result
> is a large number of C and COBOL programs written with strong typing.

Why are you trying to "convert" people? This is not about religion,
is it? There is programming world outside OO. OO is not the first,
and believe me, not the last paradigm in the software world. And some
paradigms work better than OO for solving some particular problems.
And they should be used in such cases.

Regards,
Arkadiy

Relevant Pages

  • Re: LSP and subtype
    ... What is the class of problems solvable using UML? ... the language of physics cannot describe. ... whatever paradigm equivalent to 2GL/3GL ... there is still a great need for reuse and generic programming. ...
    (comp.object)
  • Re: OO Methodolgy Perspective
    ... on a methodology like XP (eXtreme Programming) or other Agile ... One of the problems with Structured Programming was that everything about the solution was expressed in computing space terms. ... One thing the OO paradigm brought to the table were a set of step stones to bridge that gap in a systematic way. ... But if the OOA/D has been done correctly, ...
    (comp.object)
  • Re: New paradigm of introspective OO development
    ... > of serious programming work experience, ... and less to talk of "new paradigm". ... Formalization is essential, imho, ... Ideas are always worth exploring - keep in mind that fixing ...
    (comp.object)
  • Re: New paradigm of introspective OO development
    ... > of serious programming work experience, ... and less to talk of "new paradigm". ... Formalization is essential, imho, ... Ideas are always worth exploring - keep in mind that fixing ...
    (comp.lang.cpp)
  • Re: Paradigms which way to go?
    ... Fabio Fracassi wrote: ... > On purpose, C++ is not strictly an OO Language, but a multi paradigm ... can either be a swiss army knife and serve several programming paradigms ...
    (comp.programming)