Re: Let's put this to rest

On Thu, 15 Jun 2006 16:55:12 +0100, "S Perryman" <a@xxxxx> wrote:

"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in message
news:WXekg.4135$n93.1619@xxxxxxxxxxx

Responding to Perryman...

You are asking for an OOP class definition, not an OOA model. Stick to
the original challenge and find an example in either book that you can
demonstrate would be done differently by "most people" because of some
fundamental difference in design methodology.

1. Already done. In a few seconds. No problem whatsoever.
So what I have is an OOA model for a stack.

A stack is almost always an implementation artifact for an ordered
collection. Whether one needs an ordered collection or not and how that
ordering should be done, if needed, depends on what the problem being
solved is, which you have not specified.

But IF a stack was needed to solve the problem, it would usually be
represented in the OOA model as:

1 R1 <<ordered>> *
[A] ---------------------- [B]

IOW, <<ordered>> and 1:* (or *:*) is all one needs to know at the OOA
level of abstraction. Deciding whether one needs stacks, linked lists,
B-Trees or whatever for relationship collection classes is a tactical OOP
prerogative. [Note the 'usually' in the first sentence. There are
exceptions that depend on particular problem contexts that haven't been
defined here.]

It is exactly this sort of open-ended discussion at the wrong level of
abstraction with requirements that are a moving target that I sought to
avoid in the challenge. So I am not going to waste any more time pursuing
this further.

1. Where is the definition of push ?? top ?? pop ??
All the things in the *specification* for stack that you were given.

2. Does anyone on comp.object think that this :

1 R1 <<ordered>> *
[A] ---------------------- [B]

looks like UML specification for any stack entity that they have ever seen
or used in a software system ??

Um.. Yes, I understood it. A stack is simply a collection class,
usually an ordered list.

Adding pop/push etc is a design thing, not an analysis thing. Thats
the rub. While the notation is the same, the thinking and conceptual
level is not.

One could break down that analysis further in order to find out what
type of stack actually was used, but that really comes down to the
level of detail required. More often than not, it probably doesnt
need to be known (but it really depends on the context of the domain
being used).


.

Relevant Pages

  • Re: Lets put this to rest
    ... fundamental difference in design methodology. ... abstraction with requirements that are a moving target that I sought to ... So I am not going to waste any more time pursuing ... All the things in the *specification* for stack that you were given. ...
    (comp.object)
  • Re: Automatic Memory Management Question
    ... // The Stack class exists in the framework under System.Collections ... // It is a linked list because Stack doesn't contain a direct reference to any other Node. ... throw new Exception("Can't Pop from an empty Stack."); ... I have used wikipedia to explore nodes and linked lists. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: You dont have to move or free pointers, fragmenting your heap.
    ... so I'm quite familiar with indexing into the array that is the stack. ... With a dynamic array of pointers ... Try doing that with linked lists! ...
    (microsoft.public.vc.language)
  • You dont have to move or free pointers, fragmenting your heap.
    ... so I'm quite familiar with indexing into the array that is the stack. ... You don't have to move or free pointers, ... Try doing that with linked lists! ...
    (microsoft.public.vc.language)