Utilizzo corretto di swing

di il
6 risposte

Utilizzo corretto di swing

Buonasera a tutti. Se avete dimestichezza con la libreria swing di java forse potreste aiutarmi. Vorrei imparare swing realizzando un giochino. Ma vado subito incontro a dei dubbi. Diversi tutorial/libri/documentazioni oracle mostrano che per disegnare bisogna ereditare dalla classe JPanel e fare l'override del metodo paintComponent, tuttavia come approccio non mi piace, poichè so che una classe eredita da un'altra se ha senso tra le due la relazione "is-a". Perchè in questo caso questa regola viene violata? In giro per la rete ci sono diverse discussioni tra chi predilige questo o l'altro approccio. Vorrei chiedervi qual'è il modo secondo voi più elegante e corretto tra i due?

6 Risposte

  • Re: Utilizzo corretto di swing

    La risposta e' semplice:

    quella consigliata dalla documentazione

  • Re: Utilizzo corretto di swing

    oleg ha scritto:


    tuttavia come approccio non mi piace, poichè so che una classe eredita da un'altra se ha senso tra le due la relazione "is-a". Perchè in questo caso questa regola viene violata?
    Se fai una classe es. GameBoardPanel che estende JPanel dove disegni la "board" del gioco ... dove sarebbe la violazione? GameBoardPanel è-un pannello.
  • Re: Utilizzo corretto di swing

    Certo, messa in questo modo ha senso. Ma con questa modellazione, non viene violato il principio di sostituzione di Liskov?
  • Re: Utilizzo corretto di swing

    Il principio di Liskov lo devi tenere in mente quando scrivi l'override. Se con paintComponent vai a scrivere un file su hard disk allora lo vìoli
  • Re: Utilizzo corretto di swing

    Adesso è più chiaro. Grazie
  • Re: Utilizzo corretto di swing

    oleg ha scritto:


    Ma con questa modellazione, non viene violato il principio di sostituzione di Liskov?
    Questo principio lo devi garantire tu sapendo cosa rappresentano e fanno le classi in relazione tra di loro. Il compilatore è solo in grado di fare i controlli tecnici sulle dichiarazioni dei metodi. Le regole di Java per cui un metodo che fa l'override non può restringere il livello di accesso e non può dichiarare eccezioni checked "nuove" oppure più "ampie" (rispetto al metodo sovrascritto), servono proprio a garantire il principio di sostituibilità a livello puramente tecnico. Ma a livello concettuale sui comportamenti dei metodi lo devi assicurare tu.

    Un classico esempio di violazione è una classe Punto3D che estende Punto2D. Se fai questo, compila benissimo e funziona pure. Puoi anche mettere in Punto2D un metodo es. double distanzaDa(Punto2D p). E siccome Punto3D estende Punto2D, tecnicamente puoi fare:

    double dist = pa2d.distanzaDa(pb3d);

    compila benissimo e funziona (distanzaDa userà solo x/y del Punto3D se non "sa" nulla di più specifico). Ma .... NON ha senso. Queste cose le devi impedire tu ... non facendole ... (non facendo questa estensione)
Devi accedere o registrarti per scrivere nel forum
6 risposte