Re: OO Design induces an existential crisis

AndyW wrote:
> On 27 Jul 2005 06:27:19 -0700, hansewetz@xxxxxxxxxxx wrote:
>
> >AndyW wrote:
> >> On Sun, 10 Jul 2005 10:49:01 +0200, "Ilja Preuß" <it@xxxxxxxxxxxxx>
> >> wrote:
> >>
> >> >AndyW wrote:
> >
> >> Identity: Coffee cup.
> >
> >> This is a mind boggler - because in purism the cup only has one state
> >> and that is that it exists. This is the state apart from the one
> >> implied by its intended usage. Currently the one on my desk merely
> >> exists since its not being interacted with.
> >
> >This idea of 'purism' sounds like pure nonsense. When you model a
> >problem, using OO or non OO methods, you base your model on your
> >perception of the world. Depending on the context and your objective
> >you will model your cup in different ways.
> >
> I suspect that you missed the very first post in the thread that sets
> out the model being used in the rest of the thread.
>
> If you had read it, then it sets out that there are different
> techniques used when modeling pure object, abstractions, services and
> mixins. The main technique is to understand what each is and learn
> to recognise them, then use the appropriate technique to model them.

I have started to believe that this discussion is not so useless after
all. However, it is not because of the content it is useful but because
of its lack of content. It many ways it is a poster child for some
other discussions on the newsgroup.

You are stating some ideas about how to model problems/solutions using
objects, abstractions etc. What is missing is a 'description' off
what these things are. I admit you supply a half baked description
based on 'tangibility' that does not hold up after a few seconds
scrutiny. Your ideas also lack an 'explanation' for why they should
work, i.e., help in building better software.

The lack of description together with the lack of explanation makes the
ideas rather useless for a reader (at least for me). Even the guys
promoting TDD, which I do not agree with, provide better descriptions
of TDD together with explanations for why TDD should work. Your
postings lack both of these two ingredients.

Regards,
Hans Ewetz

.

Relevant Pages

  • Re: Force/Power + CHI
    ... Caught that; again, in our art, we had a different approach to energies; our exercises concentrated on the sensing of directed intent more than the involvement of energy in strikes. ... the average untrained joe can see that chi is real. ... it's simply too generic and has a readily available and much simpler muscular explanation. ... It's an acknowledged technique within Chinese ...
    (rec.martial-arts)
  • Re: Counting knight moves
    ... What diagrams would you suggest to enhance the explanation? ... where is the knight in relation to that square? ... because there's a similar rule in Alexander's Technique, ... evaluated and tried out several knight positions relative to a 3x3 ...
    (rec.games.chess.misc)
  • Re: First Avoid Coding
    ... Ron Jeffries wrote: ... >>surrounding the term TDD in the past by XP'ers. ... >>to be the only XP notable stating that TDD is the primary driver of ... >technique very likely does. ...
    (comp.object)
  • Re: TDD sucks [Was: Snake Oil]
    ... > TDD is both a low-level design technique and a high-level requirements ... TDD alternates between making simple edits to pass tests with poor ... and refactoring to improve the structure and emerge a design. ... > they balance the weaknesses of other best practices, ...
    (comp.object)
  • Re: Paris Masters Draw -- Poor Safin
    ... you'll never understand that is sad in its own right. ... This smacks very much of you wanting to elevate a player you feel an ... with technique. ... Try to give us a "technical" explanation of why Rembrandt's _The Night ...
    (rec.sport.tennis)