List interface for Vector

in ThingTestDriver.java the line:

ListOfThings aList = new ListOfThings();

works fine.  I'd prefer:

List aList = new ListOfThings();

which gives the following error:

ThingTestDriver.java [10:1] cannot resolve symbol
symbol  : class List
location: class ThingTestDriver
List aList = new ListOfThings();
^
1 error
Errors compiling ThingTestDriver.




public class ThingTestDriver {

private ThingTestDriver() {
System.out.println("ThingTestDriver default constructor..");
}//ThingTestDriver

public static void main(String[] args) {
System.out.println("ThingTestDriver main..");

List aList = new ListOfThings();

for (int i=0; i<5; i++){
Thing aThing = Thing.getInstance();
aList.add(aThing);
}//for

System.out.println(aList.toString());

System.out.println("..ThingTestDriver main..done.");
}//main

}//ThingTestDriver



public class ListOfThings extends java.util.Vector {

public ListOfThings() {
System.out.println("ListOfThings..");
}//ListOfThings

public ListOfThings getInstance() {
System.out.println("..getCollectionOfThings..");
return new ListOfThings();
}//getInstance

public static void main(String[] args) {
System.out.println("ListOfThings main..");
}//main

}//ListOfThings





thanks,

Thufir Hawat

<thufir.hawat@mail.com> wrote in message
news:Pine.LNX.4.60.0407242010540.3730@F0106000nr6n02427.ip.funjpnoyr.arg...
> in ThingTestDriver.java the line:
>
>   ListOfThings aList = new ListOfThings();
>
> works fine.  I'd prefer:
>
>   List aList = new ListOfThings();

import java.util.List;

This is beside the point that:
a) inheriting from Vector or any List implementation is ugly (investigate
the decorator design pattern).
b) Using a Vector is generally not the correct implementation to use -
http://www.xdweb.net/~dibblego/java...nswers.html#q35

--
Tony Morris
http://xdweb.net/~dibblego/

On Sun, 25 Jul 2004, Tony Morris wrote:
[..]
> import java.util.List;

doh! thanks.

> This is beside the point that:
> a) inheriting from Vector or any List implementation is ugly (investigate
> the decorator design pattern).
> b) Using a Vector is generally not the correct implementation to use -
> http://www.xdweb.net/~dibblego/java...nswers.html#q35
[..]

a] hmm, I'll check out decorator.  would you care to add to to that
pointer?  I was thinking of making the list a singleton...

b] I know, at least I'll be referencing it via List :)  IIRC vector's
convenient, though, because it's thread safe, or something.  yes, down the
road I'll change it.


thanks,

Thufir Hawat

<thufir.hawat@mail.com> wrote in message
news:Pine.LNX.4.60.0407250241140.3088@F0106000nr6n02427.ip.funjpnoyr.arg...
> On Sun, 25 Jul 2004, Tony Morris wrote:
> [..] 
>
> doh! thanks.
> 
(investigate 
> [..]
>
> a] hmm, I'll check out decorator.  would you care to add to to that
> pointer?  I was thinking of making the list a singleton...

I assume you mean you are going to create an object that wraps a List and
that object is a singleton.

> b] I know, at least I'll be referencing it via List :)  IIRC vector's
> convenient, though, because it's thread safe, or something.  yes, down the
> road I'll change it.

There are a few outstanding questions - it appears that you are insisting on
using known 'anti-patterns' - things that are known to be flawed.

Here are some questions:
a) Why must the encapsulating object be a singleton?
b) Why must the List be thread-safe?
c) If there is a justifiable answer to b), why aren't you using the
appropriate mechanism supplied by the Java 2 Collections API?
d) Why are you inheriting from a List implementation? (this is seldom, if
ever, justifiable)
e) Why are you inheriting from anything anyway, since it appears that you
aren't providing any additional functionality - just inheriting for the sake
of it.

The decorator design pattern is well documented - www.google.com

--
Tony Morris
http://xdweb.net/~dibblego/

On Sun, 25 Jul 2004, Tony Morris wrote:
> a) inheriting from Vector or any List implementation is ugly (investigate
> the decorator design pattern).
[..]

from <http://builder.com.com/5100-6370-1051793.html>, some whitespace
edited out:

public class ActionDecorator implements Action {
private Action action;
public ActionDecorator(Action action) {
this.action = action;
}
public void act1() {
action.act1();
}
public void act2() {
// do nothing
}
}

Action is Swing?  like action event, or along those lines?  most examples
of Decorator/Wrapper seemed to deal with i/o, since java i/o uses this
pattern extensively.

I'd do something like:

public class VectorDecorator implements Vector {
//implements List makes more sense..?
private Vector vector;

public VectorDecorator (Vector vector) {
this.vector = vector;
}//VectorDecorator

public void add (Object object) {
vector.add(object);		//is this necesarry?
}//add
}//VectorDecorator

seems an awful lotta work..I'd have to *manually* do add() to be able to
use add()?  what about all the other List methods, I need to add those,
too?  please clarify.

thanks,

Thufir Hawat

class X implements List {
private List l;

...
}

The decorator design pattern is formally defined - this is an example of a
List decorator.
Still doesn't answer my questions.

--
Tony Morris
http://xdweb.net/~dibblego/

On Sun, 25 Jul 2004, Tony Morris wrote:
[..]
> There are a few outstanding questions - it appears that you are insisting 
on
> using known 'anti-patterns' - things that are known to be flawed.
>
> Here are some questions:
> a) Why must the encapsulating object be a singleton?
> b) Why must the List be thread-safe?
> c) If there is a justifiable answer to b), why aren't you using the
> appropriate mechanism supplied by the Java 2 Collections API?
> d) Why are you inheriting from a List implementation? (this is seldom, if
> ever, justifiable)
> e) Why are you inheriting from anything anyway, since it appears that you
> aren't providing any additional functionality - just inheriting for the sa
ke
> of it.
>
> The decorator design pattern is well documented - www.google.com
[..]
e:  to experiment with collections, maybe shouldn't be inheritance.
d:  it's more that I want to use the list interface, leaving flexibility
to try different list implementations down the road.
c:  I'm postponing using this/these mechanisms for the time being.  Vector
hides those mechanisms from me, which I want.  As I progress in this area
I'll drop the Vector for whatever's more appropiate.
b:  it doesn't, for now.  IIRC I've run into error messages compiling with
other types of collections.  By using a Vector that potential PITA is
circumvented.
a:  the sixtyfour thousand dollar question: to do it.  If I'm using
anti-patterns clearly I need to move into using patterns; singleton is
such a pattern.  It's an exercise to play with a singleton and
collections.

I'll be doing some thinking on where this is all headed, which might be
why I'm using the anti-pattern. ?

thanks,

Thufir Hawat

On Sun, 25 Jul 2004, Tony Morris wrote:

> class X implements List {
>    private List l;
>
>    ....
> }
>
> The decorator design pattern is formally defined - this is an example of a
> List decorator.
> Still doesn't answer my questions.
>
> --
> Tony Morris
> http://xdweb.net/~dibblego/

to make the List a singleton I *believe* it should extend one of the
collections which implements the list interface.  It's just an exercise in
trying to use at least one pattern.  I'm moving away from the vector by
referring to it by its interface, this lets me change the collection
with a minimal ripple effect, I *believe*.   I'm operating with some
assumptions, hence the "beliefs."

Thufir Hawat

On Sun, 25 Jul 2004 thufir.hawat@mail.com wrote:
[..] 
>
> to make the List a singleton I *believe* it should extend one of the
> collections which implements the list interface.  It's just an exercise in
> trying to use at least one pattern.  I'm moving away from the vector by
> referring to it by its interface, this lets me change the collection with 
a
> minimal ripple effect, I *believe*.   I'm operating with some assumptions,
> hence the "beliefs."
>
> Thufir Hawat
>

to expand on the above:  I'm finding some info on decorator, but it's slow
going and will take some time for me.  By picking the pattern ahead of
time and working backwards to find the question which is answered by
"singleton" I know I'll be working on singleton.  Until I get a few
patterns under my belt, this seems the best way to learn the patterns, one
at a time. ?