Re: Databases as objects

topmind wrote:

S Perryman wrote:

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

TM>They are often worded as "adding an X without having to change Y".

Please give us an exact reference to all the GoF patterns that are
worded in the manner that you claim.

Page numbers in the GoF book would be most helpful. Failing that, the
pattern names will suffice.

How come the claimer of "motivation" is not subject to your page-number
citation harassment also? Dare I say, "double standard"? You jumped
right over their claims. How convenient.

I have done no such thing. Again, you claim that the sections of the
GoF patterns that are labelled "motivation" :

<quote>
are often worded as "adding an X without having to change Y".
</quote>


I have the GoF book in front of me.
I have quickly scanned the "Motivation" sections of a few patterns, and
see no text of the form you claim.

So (my laxness/laziness aside) , the burden of proof is on you to show
us where in the book there are sections worded as you claim.

If you are unable to do so, retract the claim.


TM>Until they are proven better in my domain

And what precisely is your "domain" ??

I expect *specific* infomation here (on-line shopping catalogues, share
dealing systems, inventory control etc) .

That is unrealistic.

No.

The boundaries a somewhat fuzzy.

No.

What are you implying?

Nothing.

I want to *know* what domains you *work or have worked in* .
And more specifically, the types of systems in those domains.


TM>with inspectable public
TM>source code, I shall use procedural/relational techniques instead and
TM>recommend others ignore them also.

A recommendation that by your own admission is based on opinion and not
fact.

The default is not OO.

By definition (obviously - you dislike OO so why would you recommend
it) .


TM>The bottom line is that you cannot prove GOF OO better.

Pick a GoF pattern, and we can construct an example that you can use to
illustrate that your preferred development methods are superior to.

I never claimed they were objectively superior. I believe paradigm
benefits are probably subjective. There are many roads to the same
solution and people pick what best fits their head.

So you do not have GoF patterns +/- real-world examples of their use for
which we can discuss whether they are better than your preferred
development methods.


- cite any personal real-world experience of working on OO projects
where a problem you claim exists can be explained to us by example.

Pro-OO's haven't either. Show me specifics where procedural/relational
is objectively worse in biz apps (and not language-specific faults).
Double Standard.

What is a "biz app" ??

If you mean "business application" , then is not the vast majority of
s/w written with intended application in some business somewhere ??

If not, provide *specific examples* of a "biz app" .


- construct a decent example that illustrates a specific problem that
you claim exists.

Same with you with regard to procedural/relational. D.S. again.

TM>but OO is not proven better outside of systems software.

Is OO is proven better *inside* of systems software ??

I did not claim that.

Who said that you did ??

Again, you wrote :

"but OO is not proven better outside of systems software."

I am asking whether it has been proven better *inside* of systems
software. If it has not, why did you write the above statement in the
first place ?? What meaning can be deduced other than that OO s/w has
been proven better in a specific subject domain ??


I am only saying I am not challenging OO in systems software.

And now I am asking : why not ??

The same alleged problems/failings of OO must surely manifest themselves
in "systems software" as in "biz apps" (whatever the latter might be) .

What is the issue with "systems software" that you cannot discuss it in
the context of OO development ??


You read what you want to read, not what is actually there.

I am reading only what you have written.
IMHO you appear to not even be capable of understanding why you write
things in the first place.


Regards,
Steven Perryman
.

Relevant Pages

  • Re: Top five object/patterns books
    ... >> overview of program structure. ... , Jacobsen, Fowler, GOF of course. ... >> The thing that got me curious is a comment in a patterns book. ... Fowler's book (Patterns of Enterprise App Architecture). ...
    (comp.object)
  • Re: OO, I just dont get it.
    ... Hey Punit. ... It only shows that the subject "Patterns" is ... In fact I leeched that GoF site (with all the ... >> I am gratefull for so many replies by the way. ...
    (comp.object)
  • Re: Head First Design Patterns
    ... If you read and understood the GoF book, ... HFDP covers a small subset of the GoF patterns, ... but even though the incremental exposure of the strategy pattern make one ...
    (comp.object)
  • Re: Head First Design Patterns
    ... In this class we used the original GoF text and went through each one of the patterns. ... Now I'm eager to continue learning about design patterns, and I bought this Head First Design Patterns. ... The original GoF text presents its content in a very familiar academic format, in contrast with the HFDP text, which is in a very informal language, full of pictures and jokes. ...
    (comp.object)
  • Re: Design Patterns in Fortran 90/95/2003 ?
    ... I also don't have my GoF book in front of me, ... I have very big doubts that all the patterns from the ... even Fortran 2003. ... But would it be as easy to implement the design patterns ...
    (comp.lang.fortran)