Erstatte kaffekop

Ja.
I et program jeg har lavet er hovedvinduet et JFrame. I constructoren er der tilføjet følgende:


icon = new ImageIcon(\"key.gif\");
this.setIconImage(icon.getImage());       

hvor \"this\" henviser til JFrame og \"key.gif\" er det ønskede billede...

ladyhawke>> Lige et spørgsmål om stil :-)

I din applikation siger du at du har extended JFrame for at udføre din applikation. Man skal normalt kun bruge arv til at lave en bedre udgave af en JFrame (dvs. en generisk component), istedet for som du ønsker i din app at anvende en JFrame.

Lad mig give et eksempel, du har skrevet class X, og jeg har skrevet Class Y:
class X extends JFrame {
  public X() {
    super(\"My frame\");
    ...
    pack();
    setVisible(true);
  }
}

class Y {
  private JFrame frame;

  Y() {
    frame = new JFrame(\"My Frame\");
    frame. ...
    frame.pack();
    frame.setVisible(true);
  }
}

De udfører i bund og grund det samme. Du anvender arv, jeg anvender composition.

Nu er det jo sådan med software, at det er genstand for iteration, refactoring, modification, bugfixes etc, så en eller anden knude kommer og skriver følgende kodestump:

X x = new X();
x.setVisible(false);

Y y = new Y();
y.setVisible(false);

I eksempel X bliver der invokeret en sekvens, som vi aldrig havde forestillet os skulle være muligt, og fejlen vil typisk havne på dit bord med ordene \"hvorfor virker din applikation ikke?\". Når du så har brugt oceaner af tid og fundet linien, vli du så sige, at man ikke må invokere metoden setVisible(boolean) med false, fordi så kan man ikke se din app. Hvorfor er metoden der så public tilgængelig :-) Der findes andre og værre metoder at anvende, men ikke desto mindre et faktum. Meget ekstra public funktionalitet som uforvarende kan blive kaldt.

I eksempel Y vil compileren ikke compilere det, fordi der ikke er andre metoder i Y end konstruktoren. Hvis det så viser sig, at et behov måtte opstå, som følge af forandringsønsker, kan vi lave den:
public void setVisible(boolean b) { frame.setVisible(b); }
Og er bedre i stand til at dokumentere virkningen, fordi vi selvfølgelig opdaterer vores javadoc/projektdokumentation.

Det er en klassisk fejl, som rigtig mange begår, inklusiv mange forfattere, som bare ikke har forstået det med OO helt :-)

Arv betyder at MyApp er en JFrame, og en JFrame er eksempelvis MyApp, og det er jo ikke helt rigtigt. Jeg siger: MyApp bruger en JFrame, og en JFrame er den ramme hvori MyApp eksisterer.

Brug derfor composition (Y) i stedet for arv (X) i langt de fleste tilfælde. Jeg har lært af erfaring :-)

Du har for så vidt ret, men nu var det ikke lige frem hele mit program jeg sendte :-)

Det var kun en lille del af et større show, der sagtens kan laves mere OO korrekt, men jeg er relativt ny i faget. Projektet er en del af softwaren til et automatisk overvågningssytem (kameraovervågning forstås)

Jeg takker for lektionen og prøver at huske det til næste gang jeg skal bruge det :-)