Re: Using iterators and efficiency.
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/22/04
- Next message: Joe \: "Re: Mars Rover Not Responding"
- Previous message: Piotr Sawuk: "Re: Function object"
- In reply to: Dave Harris: "Re: Using iterators and efficiency."
- Next in thread: Robert C. Martin: "Re: Using iterators and efficiency."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 22 Jan 2004 22:29:25 GMT
Responding to Harris...
This is a classic case of getting sidetracking because the only context
is an existing solution rather than the actual problem to be solved.
> h.lahman@verizon.net (H. S. Lahman) wrote (abridged):
>
>>>The problem is that different subnodes have different
>>>representations. Some use a linked list, some use arrays. You have
>>>suggested 2 implementations, but neither will handle both kinds of
>>>subnode.
>>
>>This assumes there are collections nested within collections.
>
>
> No. It just takes the problem as the original poster said:
>
> I have two types of node that contain lists of other nodes,
> their representation internally is different.
Right; two simple collections with different collection management
mechanisms in their /implementation/. Note that this description says
nothing about there being different types of Nodes.
Given the overloading of 'node' in the description, the only thing that
makes sense here is:
0..1 R1 1
[List] -------------------- [Node]
| 1 | *
| R2 |
+---------------------------+
where, in the set of all Node instances, two instances have lists of
specific Nodes.
>
>
>
>>The OP postulated two simple collections, each with its own iterator.
>
>
> Yes, close enough. The two simple collections are in subclasses of the
> TrieNode class. A client of TrieNode does not know what kind of subclass
> he has, so doesn't know what kind of iterator to create.
But TrieNode is irrelevant to my solution. The client needs to navigate
the lists of Nodes via the R3 -> R2 relationship:
[Client]
* |
|
| R3
|
|
2 | 0..1 R1 1
[List] -------------------- [Node]
| 1 | *
| R2 |
+---------------------------+
The issue is how Client talks to List over R3 (i.e., indirectly through
an iterator or directly via a simple List.getNext). If there is a
different problem to solve that /requires/ Node to be subclassed, that's
fine. But this was the problem originally described.
[However, even if Node is subclassed, it doesn't make any difference to
how List is accessed by Client -- that subclassing is a matter between
Node and List.]
Recall that my initial question was whether iterators were needed at
all. Change the R3 multiplicity to
[Client]
1 |
|
| R3
|
|
2 | 0..1 R1 1
[List] -------------------- [Node]
| 1 | *
| R2 |
+---------------------------+
and both iterators and my solution are superfluous.
[BTW, I also see no reason why the client navigating the collection
should be creating it. That is usually symptomatic of poor cohesion in
the abstractions. Generally the rules and policies for participation in
a collaboration are quite different that the rules and policies for the
execution of the collaboration. (Factory and related patterns provide
exactly this sort of separation of concerns.) So it is rather uncommon
for either class participating in a collaboration to also be responsible
for instantiating the relationship. (A noteworthy exception <sometimes>
being whole/part.)]
*************
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: Joe \: "Re: Mars Rover Not Responding"
- Previous message: Piotr Sawuk: "Re: Function object"
- In reply to: Dave Harris: "Re: Using iterators and efficiency."
- Next in thread: Robert C. Martin: "Re: Using iterators and efficiency."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
