[JAVA] Vergelijken van artikelen lukt niet

[Verwijderd]

Ik heb een klasse Artikel, met daarin de volgende code die van belang is:

code:

public class Artikel
{
  private Int Artikelnr;                // Attributen
  private String Artikelnaam;
  private double Artikelprijs;
  private boolean Artikelis;

  public Artikel(Int artNr, String artNm, double artPr, boolean artIS) // Constructor
  {
       Artikelnr = artNr;
       Artikelnaam = new String(artNm);
       Artikelprijs = artPr;//.copy();
       Artikelis = artIS;
  }

  public boolean equals(Artikel art)        // Equals-method
  {
      return this.Artikelnr == art.Artikelnr;                   // Prim.Type
    //  && this.Artikelis == art.Artikelis                    // Prim.Type
    //  && this.Artikelnaam.equals(art.Artikelnaam);            // Ref.Type
    //  && this.Artikelprijs.equals(art.Artikelprijs);      // Ref.Type
  }

En ik heb een applet met daarin verschillende invoervelden en een checkbox en een knop met uitvoeren. Nu wil ik 2 dezelfde artikelen aanmaken en dan de functie equals gebruiken om te kijken of ze gelijk zijn, dit doe ik als volgt:

voor de duidelijkheid, ik geef Artikel1 precies dezelfde parameters als Artikel2

code:

  void artEqualKnop_actionPerformed(ActionEvent e)
  {
    Artikel1 = new Artikel(new Int(Integer.parseInt(artNrInvoerveld1.getText())),
                            artNaamInvoerveld1.getText(),
                            Double.parseDouble(artPrijsInvoerveld1.getText()),
                            artVoorraadCheckbox1.getState());
    Artikel2 = new Artikel(new Int(Integer.parseInt(artNrInvoerveld1.getText())),
                            artNaamInvoerveld1.getText(),
                            Double.parseDouble(artPrijsInvoerveld1.getText()),
                            artVoorraadCheckbox1.getState());
    if (Artikel1.equals(Artikel2))
    {
        label3.setText("Getallen zijn gelijk aan elkaar");
    }
    else
    {
        label3.setText("Getallen zijn NIET gelijk aan elkaar");
    }
  }

Maar nu zegt hij dat het niet aan elkaar gelijk is, wat doe ik fout? Als ik Artikel2 niet aanmaak. Maar Artikel2 = Artikel1 dan doet hij het wel, maar als ik ze apart aanmaak, dan doen ze het niet...

[ Voor 7% gewijzigd door Verwijderd op 23-12-2005 09:03 ]

[Infinitive]

Ligt het nu aan mij of gebruik je een integer _object_ voor het artikelnummer i.p.v. een primitieve int? Want dan gaat je (==) fout in de equals() functie. De (==) werkt namelijk voor objecten door naar de referentie te kijken en die zijn voor elk object anders.

Vergelijk:

code:

new Int(3) == new Int(3)    // false
3 == 3   // true

Maar ik kan me echter alleen herinneren dat integer objecten in Java "Integer" heten en niet "Int", of is dit het auto-boxing gebeuren?

[Nick_S]

De signature van je equals functie is volgens mij fout. Deze moet geen artikel aannemen, maar een Object, anders wordt de default equals functie van Object gebruikt.

[Verwijderd]

Ja, klopt, ik gebruik een integer_object, maar ik heb ook een functie

code:

public boolean equals(Int iObj)    // Equals-method
 {
   return this.value == iObj.value;
}

en die gaat wel gewoon goed, en nu doe ik precies hetzelfde toch?

[sig69]

Nick_S schreef op vrijdag 23 december 2005 @ 09:12:
De signature van je equals functie is volgens mij fout. Deze moet geen artikel aannemen, maar een Object, anders wordt de default equals functie van Object gebruikt.

Scherp! Was mij niet opgevallen. Ach het is nog vroeg he...
Overigens, één breakpoint in je equals methode en je was er waarschijnlijk zelf achter gekomen.

Edit: Hmm, begin nu te twijfelen. Ik zal je code eens runnen hier.

[ Voor 21% gewijzigd door sig69 op 23-12-2005 09:19 ]

[Verwijderd]

Deze moet geen artikel aannemen, maar een Object, anders wordt de default equals functie van Object gebruikt.

Dat begrijp ik niet

[icecoolsniper]

Kan je die laatste methode niet gebruiken dan? Als de 2 objecten vergeleken 0 zijn dan is je boolean true, en anders false

ik bedoel dus in deze: public boolean equals(Artikel art) // Equals-method

[ Voor 27% gewijzigd door icecoolsniper op 23-12-2005 09:18 ]

[jhksema]

Verwijderd schreef op vrijdag 23 december 2005 @ 09:12:
Ja, klopt, ik gebruik een integer_object, maar ik heb ook een functie

code:

public boolean equals(Int iObj)    // Equals-method
 {
   return this.value == iObj.value;
}

en die gaat wel gewoon goed, en nu doe ik precies hetzelfde toch?

compareTo
public int compareTo(Integer anotherInteger)Compares two Integer objects numerically.

Parameters:
anotherInteger - the Integer to be compared.
Returns:
the value 0 if this Integer is equal to the argument Integer; a value less than 0 if this Integer is numerically less than the argument Integer; and a value greater than 0 if this Integer is numerically greater than the argument Integer (signed comparison).
Since:
1.2

(http://java.sun.com/j2se/1.4.2/docs/api/)

[sig69]

Ik krijg een build error op regel 21 van je artikel class:

Cannot invoke equals(double) on the primitive type double

[PhysicsRules]

Je attribute artikelnr dat je probeert te vergelijken is private. in de equal method kan deze eigenschap voor art dus niet uitgelezen worden!

Voeg een getter toe aan je class!

Wat is trouwens een Int voor class??? Moet het niet int zijn...

code:

public class Artikel
{
  private Int Artikelnr;                // Attributen
 
  public int getArtikelnr()
 {
   return Artikelnr; 
 }

  public boolean equals(Artikel art)        // Equals-method
  {
      return this.getArtikelnr() == art.getArtikelnr();                 // Prim.Type
  }

Daarnaar voor de equals method: de enige echte equals functie moet een Object meekrijgen. Maar dat betekent niet dat wat je nu doet fout is voor je eigen gebruik. Je voldoet alleen niet aan de eisen voor het officieel implementeren van de equals method. (Kan fout gaan als je op een andere plaats je objectje voert aan een methd die ervan uitgaat dat je class wel degelijk de echte equals method heeft geïmplementeerd.

[ Voor 27% gewijzigd door PhysicsRules op 23-12-2005 09:29 ]

[Confusion]

Verwijderd schreef op vrijdag 23 december 2005 @ 09:16:
Dat begrijp ik niet

Als je equals probeert te overriden met een functie die een bepaald type, niet Object, als parameter meekrijgt, dan overload je equals, in plaats van hem te overriden. Vervolgens wordt de originele equals telkens nog aangeroepen vanuit van alles en nog wat.

[Confusion]

PhysicsRules schreef op vrijdag 23 december 2005 @ 09:25:
Je attribute artikelnr dat je probeert te vergelijken is private. in de equal method kan deze eigenschap voor art dus niet uitgelezen worden!

Een private variabele mag door andere instanties van dezelfde klasse gelezen worden. Anders zouden de meeste equals in de Java API niet werken .

[ Voor 9% gewijzigd door Confusion op 23-12-2005 09:29 ]

[PhysicsRules]

Confusion schreef op vrijdag 23 december 2005 @ 09:28:
[...]

Een private variabele mag door andere instanties van dezelfde klasse gelezen worden. Anders zouden de meeste equals in de Java API niet werken .

Prima, ik laat m'n fout wel staan als les voor zij die komen gaan na mij...

Maar wat blijft is die Int met een hoofdletter. Lijkt me de bron van problemen, want dan geeft een == natuurlijk false.

[Verwijderd]

Ik heb een getter toegevoegd, maar ook dit helpt niet...

En Int met een hoofdletter, dat moet, het moet niet de primitieve int zijn!

[Verwijderd]

En hoe moet ik die compareTo gebruiken dan?

Want het lijkt mij dat ik dan iets als:

compareTo(this.Artikelnr, art.Artikelnr) moet doen, maar hij kent comareTo niet

[Tubby]

compareTo hoor bij de Comparable interface:
http://java.sun.com/j2se/...java/lang/Comparable.html

En dit is een serieuze OO denkfout:

Verwijderd schreef op vrijdag 23 december 2005 @ 09:46:
compareTo(this.Artikelnr, art.Artikelnr)

[ Voor 59% gewijzigd door Tubby op 23-12-2005 09:54 ]

[PhysicsRules]

Verwijderd schreef op vrijdag 23 december 2005 @ 09:38:
Ik heb een getter toegevoegd, maar ook dit helpt niet...

En Int met een hoofdletter, dat moet, het moet niet de primitieve int zijn!

Dat kan, maar dan moet je de equals method van de classe Int gebruiken.

Misschien is het een hiaat in mijn javakennis, maar ik ben niet bekend met de classe Int. Wel Integer.

Als je twee objecten met elkaar vergelijkt, zelfs als ze inhoudelijk gelijk zijn zal object1==object2 false geven. Ook als deze objecten Wrapper objecten zijn (Integer, Double, Boolean enz.)

Maar misschien is het verstandig als je er eens een goed Java boek voor beginners bijpakt.
Java 2 Guide is bijvoorbeeld een prima boek waar ik zelf mijn examen mee voorbereid heb.

Tubby schreef op vrijdag 23 december 2005 @ 09:56:
[...]

Dat heb ik altijd zo vreemd gevonden, als je er goed over nadenkt is dat niet OO namelijk

ja, dat was dus de denkfout die ik ook even maakte.

[ Voor 34% gewijzigd door PhysicsRules op 23-12-2005 09:58 ]

[Tubby]

Confusion schreef op vrijdag 23 december 2005 @ 09:28:
[...]

Een private variabele mag door andere instanties van dezelfde klasse gelezen worden. Anders zouden de meeste equals in de Java API niet werken .

Dat heb ik altijd zo vreemd gevonden, als je er goed over nadenkt is dat niet OO namelijk

[sig69]

Je hebt de comparable interface helemaal niet nodig.
Als je gewoon zorgt dat je de equals methode juist override zou het allemaal gewoon netjes moeten werken.
Aan de stijl van je code te zien vermoed ik dat je in een of andere text editor werkt. Misschien een idee om een fatsoenlijke IDE te gaan gebruiken? Dit soort fouten los je doorgaans in 2 minuten op, en nu ben je toch al bijna een uur bezig.

[Verwijderd]

Nou, ik werk gewoon in Jbuilder (wellis waar versie 3 maar dat maakt niet uit)... maar begin er nu steeds minder van te begrijpen eigenlijk

[PhysicsRules]

Verwijderd schreef op vrijdag 23 december 2005 @ 10:00:
Nou, ik werk gewoon in Jbuilder (wellis waar versie 3 maar dat maakt niet uit)... maar begin er nu steeds minder van te begrijpen eigenlijk

Kun je duidelijker zijn wat je niet begrijpt?

[Verwijderd]

ik begrijp het volgende niet:

Ik heb een klasse Int met daarin de volgende constructor en methode:

code:

public class Int  // Definitie Integer-Klasse
{
    private int value;      // Attribuut

    public Int(int i)   // Constructor
    {
       value = i;
    }

    public boolean equals(Int iObj)    // Equals-method
    {
       return this.value == iObj.value;
    }

Als ik dit nu gebruik doet hij het wel...

Maar ik heb ook een klasse Artikel met daarin de volgende constructor en methode:

code:

public class Artikel
{
  private Int Artikelnr;                // Attributen
  private String Artikelnaam;
  private double Artikelprijs;
  private boolean Artikelis;

  public Artikel(Int artNr, String artNm, double artPr, boolean artIS) // Constructor
  {
       Artikelnr = artNr;
       Artikelnaam = new String(artNm);
       Artikelprijs = artPr;//.copy();
       Artikelis = artIS;
  }

  public Artikel copy()   // copy-method
  {
      return new Artikel(Artikelnr,Artikelnaam,Artikelprijs,Artikelis);
  }

  public boolean equals(Artikel art)        // Equals-method
  {

     return this.getArtNumber() == art.getArtNumber();                    // Prim.Type
//     return this.ArtikelNr == art.ArtikelNr;                                   werkt ook niet

  }

  public String toString() // toString-method
  {
      return Artikelnr + " -  " + Artikelis + " -  " + Artikelnaam + " -  " + Artikelprijs;
  }

  public void setArtNumber(Int artNr)   // set-methods
  {
      Artikelnr = artNr;
  }

  public void setArtName(String artNm)
  {
      Artikelnaam = new String(artNm);
  }

  public void setArtPrice(double artPr)
  {
      Artikelprijs = artPr;
  }

  public void setArtIS(boolean artIS)
  {
      Artikelis = artIS;
  }


  public Int getArtNumber()     // get-methods
  {

     return Artikelnr;
  }

  public String getArtName()
  {

     return Artikelnaam;
  }

  public double getArtPrice()
  {

      return Artikelprijs;
  }

  public boolean getArtInStock()
  {
      return Artikelis;
  }
}

Maar hiervan doet de equal functie het niet, maar ik doe toch precies hetzelfde bij de equal functie in de Int klasse?

[ Voor 10% gewijzigd door Verwijderd op 23-12-2005 10:09 ]

[Tubby]

en die moet je dan dus ook gebruiken.

Verder is het heel onoverzichtelijk voor ons dat je Int gebruikt ipv Integer

sig69 schreef op vrijdag 23 december 2005 @ 09:57:
Je hebt de comparable interface helemaal niet nodig.

Voor de equals functie niet, de compareTo wel, want dan kun je een List van dit object automagisch sorteren

En zoals hierboven gezegd moet je equals overriden, niet overloaden. Het overloaden van een functie met als parameter type Object niet handig. Nu zal java nog steeds Object.equals aanroepen ipv Article.equals

[ Voor 77% gewijzigd door Tubby op 23-12-2005 10:14 ]

[PhysicsRules]

ADM666:
Even een kort lesje vergelijken in Java:
Geheugen:
Primitieven slaan getallen op in hun geheugenstukje.
Objecten zitten in de "object-hive", een pool van geheugen met allemaal objecten.
Refence-variabelen zijn getallen die verwijzen naar het geheugenadres van het object in de hive.

Nu vergelijken we:
de == operator vergelijkt de primitieve waarden van de variabelen.
Twee primitieven zijn dus gelijk als ze de zelfde waarde hebben.
Twee reference-variabelen zijn dus gelijk als ze naar hetzelfde object verwijzen.

Als je twee objecten hebt met de zelfde waarde zijn het nog steeds twee objecten met een verschillend adres. Als je de reference-variabelen dus vergelijkt met == zullen ze niet gelijk zijn.

Als je dus wilt weten of twee objecten inhoudelijk hetzelfde zijn moet je een equals-method definiëren én gebruiken.

In je code is Int een class. De artikelnr's zijn dus objecten. Twee artikelNr's met hetzelfde nummer zullen dus niet gelijk zijn voor ==, omdat ze naar verschillende instanties van Int kijken.

Gebruik dus ook voor het vergelijken van je Int's de equal-method.

Bottom line: probeer eens

code:

public boolean equals(Artikel art)        // Equals-method
  {

     return this.getArtNumber().equals(art.getArtNumber());                    // Prim.Type
  }

[ Voor 11% gewijzigd door PhysicsRules op 23-12-2005 10:19 ]

[Verwijderd]

Dux: Jij bent de beste!!!!!!!

Dan ga ik nu proberen of het ook lukt met de andere waarden... maar daar moet ik wel uitkomen!!! Allemaal van harte bedankt!

[Confusion]

Tubby schreef op vrijdag 23 december 2005 @ 09:56:
Dat heb ik altijd zo vreemd gevonden, als je er goed over nadenkt is dat niet OO namelijk

Ligt dat niet een beetje aan wat je 'OO' vindt? Een alternatief is het verplicht hebben van getters voor elke variabele die voor onderlinge vergelijking van gelijke objecten gebruikt moet worden. Dat lokt uit tot gebruik van die variabelen voor meer zaken, terwijl dat ook niet OO is. Een derde alternatief is vergelijkingsmethoden alleen van variabelen af laten hangen die om andere reden zichtbaar moeten zijn, maar dat is nogal beperkend. Je moet altijd compromissen sluiten.

[Tubby]

Java:

...
private Integer Number; 
...
public Integer getNumber()
{
   return this.number;
}

public void setNumber(Integer number)
{
   this.number=number;
}

public boolean equals(Object object)        // Equals-method
  {
     if(object instanceof Artikel)
     {
         return this.getNumber().equals(((Artikel)object).getNumber());
     }
     return super.equals(object);
  }

Confusion schreef op vrijdag 23 december 2005 @ 10:23:
[...]
Ligt dat niet een beetje aan wat je 'OO' vindt? Een alternatief is het verplicht hebben van getters voor elke variabele die voor onderlinge vergelijking van gelijke objecten gebruikt moet worden. Dat lokt uit tot gebruik van die variabelen voor meer zaken, terwijl dat ook niet OO is. Een derde alternatief is vergelijkingsmethoden alleen van variabelen af laten hangen die om andere reden zichtbaar moeten zijn, maar dat is nogal beperkend. Je moet altijd compromissen sluiten.

Klopt, zelf genereer ik altijd alle getters en setters

[ Voor 71% gewijzigd door Tubby op 23-12-2005 10:28 ]

[sig69]

Hmm, ben beetje traag vandaag, maar ik post toch nog maar even.
Ik heb even wat opmerkingen geplaats:

Java:

public class Artikel
{
    private Int Artikelnr; // Waarom geen Integer?
    private String Artikelnaam;
    private double Artikelprijs; // Waarom artikelnummer een object en prijs een primitive?
    private boolean Artikelis; // Idem

    public Artikel(Int artNr, String artNm, double artPr, boolean artIS) // Constructor
    {
        Artikelnr = artNr;
        Artikelnaam = new String(artNm); // Artikelnaam = artNm volstaat ook
        Artikelprijs = artPr;//.copy();
        Artikelis = artIS;
    }

    public Artikel copy()   // copy-method <- overbodig
    {
        // Dit is geen correct copy methode, aangezien ArtikelNummer een object is
        // en de reference dus behouden blijft
        return new Artikel(Artikelnr,Artikelnaam,Artikelprijs,Artikelis);
    }
    
    // Onjuiste override van equals metode
    public boolean equals(Artikel art)        // Equals-method < <- overbodig
    {
        // Artikelnr is een object en kan je dus niet met == controleren
        return this.getArtNumber() == art.getArtNumber();                    // Prim.Type
        //     return this.ArtikelNr == art.ArtikelNr;                                   werkt ook niet
}

Ik zou het zoiets doen:

Java:

public class Artikel
{
    private Integer artikelNr;
    private String naam;
    private Double prijs;
    private Boolean artikelIs;
        
    public Artikel(Integer artikelNr, String naam, Double prijs, Boolean artikelIs)
    {
        this.artikelNr = artikelNr;
        this.naam = naam;
        this.prijs = prijs;
        this.artikelIs = artikelIs;
    }
    
    public boolean equals(Object obj)
    {
        Artikel a = (Artikel)obj;
        
        return 
            artikelNr.equals(a.artikelNr) &&
            naam.equals(a.naam) &&
            prijs.equals(a.prijs) &&
            artikelIs.equals(a.artikelIs);
    }   
}

[Tubby]

Mja, genoeg tips iig

[Paul]

Je vergelijkt het volgende: return this.Artikelnr == art.Artikelnr; Artikelnr is echter een Int ipv een primitieve integer, waardoor de referenties worden gecontroleerd, en die zijnvoor beiden anders.
Je geeft ook al aan dat je een Int.equals hebt. Je bent je er dus van bewust dat een == op 2 classes niet werkt zoals jij hier bedoelt. Echter, gebruik die .equals dan ook Nu zit je nog steeds referenties te controleren ipv de inhoud.

Of gooi die Int's overboord en gebruik integers Tenzij ze een doel hebben dat ons (mij) nog niet duidelijk is

[Verwijderd]

ik dank u allen hartelijk!!!!! ik ben eruit!! en snap het nu ook helemaal volgens mij!! (dat is nog het belangrijkste!)

[Tubby]

De kanttekeningen van sig69 mbt tot de benaming kloppen ook wel

Artikel.artikelnr is imho overbodig
Artikel.nummer is genoeg
Artikel.naam

veel duidelijke, anders krijg je van die onnodig onduidelijk en lange functie namen Artikel.getArtikelNr() ipv Artikel.getNumber()

[Verwijderd]

je hebt in java de klasse Integer tot je beschikking, dus je hebt int en Integer en verder niets en volgens mij volstaat het primitieve int prima.
Verder kan het volgens mij geen kwaad je eens in privates en publics te verdiepen.

o, je bent er uit. Maar je nog wat verdiepen op publics, privates, instanties van objecten met referenties en primitieven kan volgens mij nog steeds geen kwaad

[ Voor 27% gewijzigd door Verwijderd op 23-12-2005 10:37 ]

[Verwijderd]

Ja, daar ben ik me dus nu in aan het verdiepen...
en ik wil dat met de klasse Artikel er geen referenties naar de attributen kunnen worden doorgegeven... maar dat klopt nu toch ook?

[grhmpf]

Je moet altijd de equals van Object overriden (dus equals(Object o)) als je wilt dat constructies als List.contains(artikel) gaan werken. Tevens zou je als je equals implementeert ook hashCode moeten implementeren...vrij basic Java!

[kasper_vk]

Verwijderd schreef op vrijdag 23 december 2005 @ 10:41:
Ja, daar ben ik me dus nu in aan het verdiepen...
en ik wil dat met de klasse Artikel er geen referenties naar de attributen kunnen worden doorgegeven... maar dat klopt nu toch ook?

Volgens mij niet, als ik de volgende getter bekijk:

Java:

public Int getArtNumber()        // get-methods
  {

     return Artikelnr;
  }

Je geeft hier namelijk gewoon een referentie naar dat Int object genaamd ArtikelNr*. Ik vermoed dat je een klasse Int hebt gemaakt die mutable is, dit in tegenstelling tot Integer. Als dat zo is dan kan iemand dus via bovenstaande getter een refentie krijgen naar je artikelnummer en (de waarde van de int-value binnen) het nummer vervolgens wellicht veranderen.

Overigens denk ik, als ik het topic zo eens lees, dat het gebruik van die eigen Int klasse voor jou de zaak alleen maar heeft vertroebeld (dat is volgens mij ook al eerder gezegd).
Dus nogmaals: waarom gebruik je die eigen Int klasse en waarin verschilt ie van Integer?

* Overigens, iets heel anders: de namen van attributen ('object-variabelen' dus) moeten, volgns de Java conventie, met een kleine letter beginnen. Dus geen ArtikelNr maar artikelNr.

[ Voor 3% gewijzigd door kasper_vk op 23-12-2005 10:53 ]

[jvo]

Dit is inderdaad vrij standaard allemaal. Maar goed, even uitgaande van de code gepost in het begin en ervanuitgaande dat je een int gebruikt i.p.v. een Integer. (Een eigen Int klasse is waarschijnlijk niet nodig.)

Java:

public class Artikel
{
  private int artikelNr;
  private String artikelNaam;
  private double artikelPrijs;
  private boolean artikelIs;

  public Artikel(int artNr, String artNm, double artPr, boolean artIS) // Constructor
  {
       artikelNr = artNr;
       artikelNaam = new String(artNm);
       artikelPrijs = artPr;
       artikelIs = artIS;
  }

  public boolean equals(Object o)
  {
    if (!(o instanceof Artikel)) return false;
    Artikel art = (Artikel)o;
    if (artikelNr != art.artikelNr) return false;
    if (!artikelNaam.equals(art.artikelNaam)) return false;
    if (artikelPrijs != art.artikelPrijs) return false;
    return artikelIs == art.artikelIs;
  }

De conventie is om variabelen met een kleine letter te laten beginnen overigens.

[Verwijderd]

Tubby schreef op vrijdag 23 december 2005 @ 10:24:
Klopt, zelf genereer ik altijd alle getters en setters

Alleen de getters en setters genereren die je daadwerkelijk gebruikt. Kwakkeloos getters en setters genereren levert enkel redundante code.