Re: Why use relational tables in OO (please just take a look inside)
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 03/18/04
- Next message: H. S. Lahman: "Re: xp and simple design"
- Previous message: Thomas Gagné: "Re: dynamic type checking - a pauline conversion?"
- In reply to: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Next in thread: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Reply: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 18 Mar 2004 18:48:22 GMT
Responding to Vertleyb...
>>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.
The P in OOA/D/P /is/ OOP. One of the things the OO approach brought
to the table was a clearer demarcation between analysis, design, and
programming than that provided by SA/SD/SP.
OOA => a solution for only functional requirements requirements that is
independent of the implementation space. (For example, in translation
the exit criteria for OOA is very clear: when the test suite for
functional requirements executes correctly against the OOA model on is
done.)
OOD => a strategic solution of nonfunctional requirements in a
particular implementation environment. [Strategic in the sense of broad
decisions like caching strategies, identifying concurrent processing
elements, and defining distributed boundaries. Some would refer to it
as an architectural solution.]
OOP => a tactical solution of nonfunctional requirements in a particular
implementation environment. [Tactical in the sense of a particular OOPL
syntax, implementing J2EE syntax, or selecting the best collection class.]
The problem is that the OOPLs make too many compromises with the
computational model (e.g., they are all inherently procedural). So
unless one does the OOA/D properly to ensure those compromises are
benign, one doesn't get an OO application despite the syntactic sugar.
An analogy would be doing functional programming littered with monads
that emulate object state variables.
>
>
>>Which? That I can provide such a library? That my "by hand" code will
>>be just as maintainable?
>
>
> Latter.
Then I think the nested typedefs speak for themselves. That sort of
macroizing is a nightmare to maintain.
>
>
>>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 never said OO was perfect and I have been on record many times on this
forum in saying that there are applications where one is better off not
doing OO at all. In fact, I have said exactly that in this thread when
I talked about RAD IDEs for CRUD/USER pipeline applications. For that
sort of data management one /should/ use the query-based relational
paradigm rather than OO development.
It is also a waste of time to use OO for pure scientific programming
where the requirements (the mathematical algorithms) are invariant over
time. Functional programming is a much better choice there than either
OO or query-based relational. OO development is also usually not very
cost effective small applications where long-term maintainability is
probably not a problem.
But where OO shines is in dealing with large, complex problem solutions
with lots of complex processing using unique business rules and
policies. In those cases one isolates persistence access from the
solution in a subsystem or layer so that the solution is indifferent to
RDB, OODB, flat files, or clay tablets as a persistence mechanism.
>
> 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.
You are describing bad OOA/D. Encapsulation and cohesion are all about
isolating unique responsibilities in one place and talking to them
directly as needed. As far as pointers in multiple places, how is that
bad compared to having referential attributes to the same tuple embedded
in many tuples from other tables? Referential integrity has to be
defined somehow.
>
> 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?
The responsibility for maintaining both subsets will <almost always> be
handled be whoever manages adding/removing employees of the parent set.
IOW, it will be done exactly where you add/remove employees from your
index.
>
> 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.
I NEVER said that. I said that if one is going to use OO, then one
should stick with it and not mix in other paradigms.
>
> 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.
C++ is also the most technically deficient of all the popular OOPLs by a
large margin precisely because it is serving so many masters. For the
same reason, it is also one of the most difficult languages (OOPL or
not) to use without foot-shooting. There is something wrong when one
can find books with titles like "101 Traps and Pitfalls of C++" (though
I think it is now out of print).
>
>
>>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.
I am not trying to convert anybody. I am simply trying to ensure that
people who do use the OO approach don't abuse it.
Frankly I have no idea where you are getting this stuff and why you are
so blatantly misquoting me in this message. I am disappointed because
up to now this has been a reasonable discussion, which was refreshing
compared to Novoa et al from the all-the-world-is-a-DBMS school.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
- Next message: H. S. Lahman: "Re: xp and simple design"
- Previous message: Thomas Gagné: "Re: dynamic type checking - a pauline conversion?"
- In reply to: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Next in thread: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Reply: Arkadiy Vertleyb: "Re: Why use relational tables in OO (please just take a look inside)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
