Re: Databases as objects


S Perryman wrote:
topmind wrote:

Patrick May wrote:

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:

Patrick May wrote:

PM> You've got it backwards. You used the Visitor pattern in
PM>support of one of your claims in your conversation with Neo. I
PM>simply pointed out that it does not, in fact, support your
PM>argument. The burden of proof is still on you to provide an
PM>example of OO techniques leading to "tangled pasta".

TM>There are no real rules for when to use what GOF pattern, especially
TM>if there are competing factors. The rules of relational
TM>normalization are governed mostly by duplication removal. All else
TM>being equal, consistency trumps inconsistency.

So you can't provide an actual example. You should just come out
and say so.

How exactly does one provide examples to show that there are no
consistent consensus rules for something?

I contend that GoF have such rules: they are labelled "motivation" etc .

They are often worded as "adding an X without having to change Y".
However, change needs often change over time. Up-front change needs are
often not a good guide to future change needs.



If I say "There is no
evidence that unicorns exist", you cannot ask for an example. It is
YOUR burden to show that unicorns exist. Now, replace unicorns with
"consistent consensus rules".

Counter-argument : it is easier to *disprove* something than it is to
*prove* it. ***

Proofs are universal : they must hold under all conditions.
Dis-proof is existential : only one condition has to be found to render
a proof statement invalid as it stands.


Okay, I declare "tangled pasta" a subjective opinion. However, there is
no evidence of GOF OO patterns improving realistic business logic.
Until they are proven better in my domain with inspectable public
source code, I shall use procedural/relational techniques instead and
recommend others ignore them also.



So, as far as GoF patterns go (and using your weird language) :

show us *one* "inconsistent consensus rule" .


It is *your burden* to show that one condition.

If you cannot, as Patrick May has so amusingly had you squirming over
the months on various different threads trying to avoid, state that
while you have doubts as to the veracity of something, you specifically
do not have the proof (and/or ability) to disprove the veracity.

The bottom line is that you cannot prove GOF OO better. Mr. May likes
nitty side-tracks to distract from the real issue. He is more
interested in bashing me than in defending OO. Kick the messenger all
you all want, but OO is not proven better outside of systems software.
Whether I am a genious or Bozo, you still have no OO proof.



Regards,
Steven Perryman


-T-

.

Relevant Pages

  • Re: Why encapsulate state pattern......
    ... >> from GoF the state pattern is to..... ... >> its interface, but you can't), then why not just change it. ... > abstraction that can have a unique identity while living as one subclass ...
    (comp.object)
  • Re: Implementing a folder object?
    ... One final note-- I tried short-cutting the implementation of the GoF ... Oranges classes. ... refactored to implement the pattern as suggested by the GoF in both classes. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Factory pattern
    ... I see that GOF made a great disservice to programming ... community by publishing their "masterpiece". ... to pattern languages). ...
    (comp.object)
  • Re: Factory pattern
    ... I see that GOF made a great disservice to programming ... community by publishing their "masterpiece". ... Dont Jump Start to pattern Catalog...Start with Beginning Chapter of ...
    (comp.object)