[JAVA] Vector van een class

[Superflip]

Nu werk ik met een array, het probleem is dat de grootte hiervan op voorhand bepaald moet zijn, dus zou ik willen werken met een vector...

Heeft iemand een idee?

Java:

/** Nu doe ik dit (met een array dus) */
private static Landen [] allelanden;

/** Onderstaande werkt natuurlijk niet */
private static Vector allelanden = new Landen();

[Boudewijn]

staat best wel heel erg letterlijk in de documentatie hoor.

Kijk eens naar vector.addelement

[ixi]

private static Vector allelanden = new Landen();
[/code]

private static Vector allelanden = new Vector();

en vervolgens:

allelanden.add(Land1);
etc.

[Woy]

Of als je met de niewste versie van Java werkt heb je ook generics het zal dan als volgt kunnen

Java:

Vector<Land> alleLanden = new Vector<Land>();

[Superflip]

ixi schreef op zondag 29 mei 2005 @ 13:56:
[...]


private static Vector allelanden = new Vector();

en vervolgens:

allelanden.add(Land1);
etc.

Nutteloos...

want je doet

allelanden.add(Land1); maar dat nummertje bij Land 1 zou ook telkens moeten verhogen... Vandaar dat een vector van de class Landen ideaal is, en niet een vector met de class Landen in.

@rwb : ik ben nu jou mogelijkheid eens aan het bekijken

[Onno]

aik0n schreef op zondag 29 mei 2005 @ 14:25:
[...]


Nutteloos...

want je doet

allelanden.add(Land1); maar dat nummertje bij Land 1 zou ook telkens moeten verhogen... Vandaar dat een vector van de class Landen ideaal is, en niet een vector met de class Landen in.

Eh?

Je hoeft geen 'nummertjes te verhogen'. Er wordt uberhaupt niks met 'nummertjes' gedaan. Wat ixi aangeeft is dat je voor elk object dat je wilt toevoegen aan je Vector .add() moet gebruiken. Daar verandert een Vector<Land> niets aan, zo werkt het nou eenmaal.

Misschien is het handig een boek of wat documentatie over Java te lezen.

[Tubby]

Een vector houdt zijn elementen wel op volgorde, het is namelijk een implementatie van List. Zoiezo wil je ArrayList gebruiken omdat Vector depricated is. Om ervoor te zorgen dat je er alleen objecten van een bepaalde classe in kunt stoppen zul je zelf een implementatie van List moeten schrijven (of ArrayList extenden en daarbij de verschillende accessors moeten overriden zodat ze alleen objecten van jouw type accepteren.

[Onno]

Tubby schreef op zondag 29 mei 2005 @ 14:43:
Zoiezo wil je ArrayList gebruiken omdat Vector depricated is.

Vector is niet deprecated.

Om ervoor te zorgen dat je er alleen objecten van een bepaalde classe in kunt stoppen zul je zelf een implementatie van List moeten schrijven (of ArrayList extenden en daarbij de verschillende accessors moeten overriden zodat ze alleen objecten van jouw type accepteren.

Daar gebruik je tegenwoordig generics voor. Wat jij hier voorstelt is niet bepaald handig.

[Superflip]

Onno schreef op zondag 29 mei 2005 @ 14:38:
[...]

Eh?

Je hoeft geen 'nummertjes te verhogen'. Er wordt uberhaupt niks met 'nummertjes' gedaan. Wat ixi aangeeft is dat je voor elk object dat je wilt toevoegen aan je Vector .add() moet gebruiken. Daar verandert een Vector<Land> niets aan, zo werkt het nou eenmaal.

Misschien is het handig een boek of wat documentatie over Java te lezen.

Sorry... je hebt gelijk

Ik denk dat het warme weer en die 4 dagen non-stop Java me parten begint te spelen

[Robtimus]

Tubby schreef op zondag 29 mei 2005 @ 14:43:
Om ervoor te zorgen dat je er alleen objecten van een bepaalde classe in kunt stoppen zul je zelf een implementatie van List moeten schrijven (of ArrayList extenden en daarbij de verschillende accessors moeten overriden zodat ze alleen objecten van jouw type accepteren.

Elke implementatie van List moet (in 1.4 en lager) ook de methods implementeren die met objecten werken, daar valt weinig aan te doen. Niemand houdt anderen tegen die te gebruiken, om zo alsnog verschillende typen in je list te krijgen.
Je zou die hooguit een UnsupportedOperationException kunnen laten throwen, maar als je dat bij alles doet is het hele principe van de List verdwenen - je kan alleen maar met je eigen class werken. Waarom zou je het dan nog een List laten zijn; een eigen wrapper is veel handiger dan:

Java:

public class ListWrapper
{
    private List list = new ArrayList();

    public void add(MyClass element)
    {
        list.add(element);
    }

    public MyClass remove(int index)
    {
        return (MyClass)list.remove(index);
    }

    public Iterator iterator()
    {
        return new MyClassIterator(super.iterator());
    }

    // etc

    private class MyClassIterator implements ListIterator
    {
        private ListIterator iterator;

        public MyClassIterator(ListIterator it)
        {
            iterator = it;
        }

        public MyClass next()
        {
            return (MyClass)iterator.next();
        }

        // etc
    }
}

[Verwijderd]

Zwaar onzinnig dergelijke wrapper classes, gewoon casten. En heerlijk je applicatie op je bek laten gaan als de cast mislukt. Dergelijke wrapper classes zijn alleen interessant tijdens ontwikkeling zodat je IDE een gave foutmelding geeft, voor de rest is het enkel meer (potententieel foutgevoelige) logica.

[Robtimus]

Verwijderd schreef op zondag 29 mei 2005 @ 17:39:
Zwaar onzinnig dergelijke wrapper classes, gewoon casten. En heerlijk je applicatie op je bek laten gaan als de cast mislukt. Dergelijke wrapper classes zijn alleen interessant tijdens ontwikkeling zodat je IDE een gave foutmelding geeft, voor de rest is het enkel meer (potententieel foutgevoelige) logica.

Zo'n wrapper is anders in Java zonder generics de enige manier om te garanderen dat alles van hetzelfde type is, en dat je dus geen ClassCastExceptions tegen zal komen. Met hobbyprojectjes zal het niet zo erg gaan als je applicatie op zijn bek gaat, maar als jij een professioneel product maakt zal het je klanten kosten als er geregeld een CCE of NPE voorkomt.

Zolang je zelf echter de volledige controle over je collections hebt vind ik het zelf ook overbodig; daarom doe ik zelf ook gewoon aan casten.

[Verwijderd]

In professionele applicaties ga je dat niet progmatisch oplossen maar declaratief. Verder is je interface doorgaans erg slecht gemodelleerd als die afhankelijk is van zulke generieke return types. Al met al zul je zo'n wrapper enkel in de hobby projectjes tegen komen.

[Robtimus]

Verwijderd schreef op zondag 29 mei 2005 @ 17:50:
Verder is je interface doorgaans erg slecht gemodelleerd als die afhankelijk is van zulke generieke return types.

Dus jij beweert hier dat het hele Java Collections Framework tot Java 1.5 slecht gemodelleerd is, omdat het zo generiek mogelijk probeert te zijn binnen de mogelijkheden van de taal?
Ik geef toe, in Java 1.5 is het sterk verbeterd met de generics, maar ik blijft het een gewaagde uitspraak vinden.

[Verwijderd]

IceManX schreef op zondag 29 mei 2005 @ 21:53:
Dus jij beweert hier dat het hele Java Collections Framework tot Java 1.5 slecht gemodelleerd is, omdat het zo generiek mogelijk probeert te zijn binnen de mogelijkheden van de taal?
.

Nee dat beweer ik niet.

[Alarmnummer]

Verwijderd schreef op zondag 29 mei 2005 @ 17:50:
In professionele applicaties ga je dat niet progmatisch oplossen maar declaratief. Verder is je interface doorgaans erg slecht gemodelleerd als die afhankelijk is van zulke generieke return types. Al met al zul je zo'n wrapper enkel in de hobby projectjes tegen komen.

Is dat zo?

Ik heb ook wel eens wrappers gemaakt voor het Collection framework: NCollections (Null Rejecting Collections) en PCollections (Collections met predicates waarbij iedere toevoeging goedgekeurd moet worden). Moet ook eerlijk toegeven dat ik ze ook nooit gebruik

[Glimi]

Hoe zit het eigenlijk met de kosten van casten op de moderne JVM's? Ik weet wel dat het 'vroeger' vrij duur was, maar als ik nu een testje draai, dan lijkt het wel mee te vallen. ongveer 800 ms verschil per 100.000.000 casts (één up en één down). Dat vindt ik nou niet echt gek veel eigenlijk.

Toen ik trouwens in dezelfde test een subclass van het testobject aan dezelfde test onderwierp met dezelfde method-call (echter die nu overridden was) dan werden de testtijden opeens vervijfvoudigd. Het maakte niet uit of er eerst gecast werdt naar de subclass of dat het gewoon via polymorphisme werd gedaan.

Linkje is misschien handig: Testclass. Kan iemand het gedrag van de test bij de subclass verklaren eigenlijk?

[ Voor 13% gewijzigd door Glimi op 30-05-2005 00:31 ]

[Robtimus]

Misschien door dit:

Java:

public String getValue() {
    return "" + super.getValue();
}

[Glimi]

IceManX schreef op maandag 30 mei 2005 @ 09:05:
Misschien door dit:

Java:

public String getValue() {
    return "" + super.getValue();
}

Je hebt helemaal gelijkt. Een klassieke fout niet
Ook gewoon B maar een harde string laten returnen en nu heb ik de volgende gemiddels na 20 maal draaien van de test.

code:

AInO           AinA        BinO        BinAP          BinAC
4032,409091 3684,136364 7782,181818 9016,090909 8074,409091

Het casten hier (van Object naar A) kost hier dus zowat 10% van de tijd tov als we de A direct in een A array stoppen.
Wat me nog steeds op blijft vallen is dat het eruithalen van de subclass B uit een Object[], casten naar een B en uitvoeren van getValue() zowat twee maal zoveel tijd kost als het ophalen van een A uit een Object[], casten naar een A en getValue() aanroepen. Komt dit puur doordat we een ge-override functie hebben aangeroepen? Want opzich door de cast naar B, zou hem toch duidelijk moeten zijn welke functie hij aan zou moeten roepen.

Dat hij dat opzich ook wel sneller doet dan een polymorphistische aanroep ( een object B uit de A[] halen, en dan de call doen ) is wel te zien uit de verschillen tussen BinAP en BinAC.

Linkje naar de versnieuwde Testcase