[JAVA] Innerclass probleempje

[rjeggens]

Ik heb het volgende stuk code voor een Observable.

code:

  Observable obTmp= new Observable() {
    public int color;

    public void setColor(int c) {
      color = c;
      super.setChanged();
    }

    public void notifyObservers(Object arg) {
      if(arg.equals(jButton1))
        System.out.println("Rood");
      if(arg.equals(jButton2))
        System.out.println("Oranje");
      if(arg.equals(jButton3))
        System.out.println("Groen");
     }
    };

Voor de aanroep probeer ik het volgende:

code:

  void jButton1_actionPerformed(ActionEvent e) {
    obTmp.notifyObservers(e.getSource());
    obTmp.setColor(1);
  }

Wat ik wil bereiken is dat ik in de observable de kleur wijzig (in dit geval in 1) en dat hij dan iets gaat doen met die knoppen. Maar goed, zover ben ik nog niet, zover KOMT ie namelijk niet. Wat het probleem is dat obTmp.notifyObservers wel werkt (hij geeft de kleur aan die hij aan moet geven). Alleen obTmp.setColor geeft als error:

code:

"ObFrame.java": Error #: 300 : method setColor(int) not found in class java.util.Observable at line 106, column 11

Ik ben nog maar net begonnen met het gebruik van innerclasses, dus misschien heb ik het principe nog niet goed in het snotje, maar ik kan volgens mij die methode met de neus aanwijzen.

Iemand een idee wat voor kapitale fout ik hier hoogstwaarschijnlijk maak?

[Tomatrix]

De foutmelding lijkt me duidelijk:
de method setColor is geen onderdeel van de Observable class in het java.util package.

Wat er overigens in het hoofd omging bij die jongens van Sun om hier een class ipv. een interface van te maken is mij een raadsel...

ah, ik zie het al:

Since:
JDK1.0

[Tomatrix]

Ik zou ook nog even je favoriete design patterns boek erbij pakken, want ik geloof niet dat je op de juiste manier gebruik maakt van het Observer pattern...

[rjeggens]

Dat boek wat we moeten hebben is helaas niet leverbaar. Ik moet het dus doen met wat dingen die ik heb opgezocht op het internet. De docent in kwestie vertelde dat het perse met een anonymous innerclass opgelost moet worden. Volgens mij is dit nodeloos ingewikkeld, aangezien ik duizendeneen voorbeelden heb gezien hoe het wel moet, maar dan door een klasse Observable te laten extenden.

Maar je hebt absoluut gelijk dat ik mijn favoriete boek er eens op na moet slaan

De foutmelding lijkt me duidelijk:
de method setColor is geen onderdeel van de Observable class in het java.util package.

Snap ik, maar ik voeg setColor toch toe door die definitie in mijn eerste stukje code?

[rjeggens]

Wat er overigens in het hoofd omging bij die jongens van Sun om hier een class ipv. een interface van te maken is mij een raadsel...

Hebben wij ook over na zitten denken. Wij kwamen tot de conclusie dat ze dat waarschijnlijk gedaan hadden om addObserver enz. te kunnen implementeren. Dit gaat volgens mij in een interface niet, daar kun je slechts het bestaan van die functies definiëren.

[Tomatrix]

Op woensdag 13 februari 2002 10:23 schreef rjeggens het volgende:
Wij kwamen tot de conclusie dat ze dat waarschijnlijk gedaan hadden om addObserver enz. te kunnen implementeren.

De juiste aanpak hiervoor is om dan een abstract class te definieren die het interface (gedeeltelijk) implementeert en de basisfunctionaliteit verzorgt, dat is veel flexibeler. Maar veel van de oudere classes in de JDK zijn nou niet bepaald fraai gedesigned.

[mbravenboer]

Ik zou inner-classes helemaal niet op deze manier misbruiken. Je maakt hier gebruik van een anonieme inner-class die ik zelfs helemaal nooit zou gebruiken.

Je probleem is simpel. Je maakt via een anonieme inner-class constructie een Observable aan met een extra methoden. Je definieert hierbij echter geen nieuwe klasse (een anonieme dus). Hierdoor blijft het type van de variabele altijd een Observable en die bevat uiteraard methode setColor niet.

Ik zou hier dus gewoon even een aparte klasse voor maken.

[rjeggens]

Zo werken al die voorbeelden idd ook. Allemaal maken ze een aparte klasse aan waarin die waarde gezet wordt. Heel simpel. Ik denk dat de docent in kwestie zich vergist heeft en dat een anonymous innerclass in dit probleem gewoon tot meer problemen dan oplossingen leidt. Ik maak er een gewone klasse van, moetie verder niet zeuren

Dank voor de antwoorden!