Classi ed interfacce

di il
9 risposte

Classi ed interfacce

Se

A=classe
B=interfaccia
C=classe

e

A implementa B
C estende A

Domanda: C deve riscrivere i metodi di B, oppure si limita ad ereditare quelli già riscritti da A?
Mi spiego meglio, se b() è un metodo di B, dovrà per forza essere riscritto da A.
Ora se C estende A, anche C dovrà riscrivere b()? oppure eredita il b() gia riscritto da A, senza riscriverlo a sua volta?

Ciao e buona domenica a tutti!

9 Risposte

  • Re: Classi ed interfacce

    Friz02 ha scritto:


    Se

    A=classe
    B=interfaccia
    C=classe

    e

    A implementa B
    C estende A

    Domanda: C deve riscrivere i metodi di B, oppure si limita ad ereditare quelli già riscritti da A?
    Se A è "concreta" (non abstract) allora deve implementare tutti i metodi di B. Poi C ha la facoltà di ridefinire tali metodi (a meno chiaramente che A li abbia marcati final, il che ovviamente preclude un override).

    Se A non è concreta, cioè è abstract, allora A non ha alcun obbligo di implementare i metodi di B. Può farlo o no .... tanto è abstract, non verrà mai istanziata direttamente. Dovrà essere estesa.

    Se C è "concreta" (e A abstract) allora è C che deve implementare tutti i metodi di B che A non ha implementato.
  • Re: Classi ed interfacce

    Friz02 ha scritto:


    Se A è "concreta" (non abstract) allora deve implementare tutti i metodi di B. Poi C ha la facoltà di ridefinire tali metodi (a meno chiaramente che A li abbia marcati final, il che ovviamente preclude un override).
    cioè se vengono marcati final non potranno essere riscritti, giusto.
    Spiegazione più che esauriente, grazie.

    Ne approfitto,
    quando trovo scritto ad esempio Class Component.AccessibleAWTComponent significa che AccessibleAWTComponent è una classe o interfaccia interna a Component?
  • Re: Classi ed interfacce

    Friz02 ha scritto:


    cioè se vengono marcati final non potranno essere riscritti, giusto.
    Sì. Una classe final non può essere estesa. Un metodo final non può essere ridefinito ("override").

    Friz02 ha scritto:


    Ne approfitto,
    quando trovo scritto ad esempio Class Component.AccessibleAWTComponent significa che AccessibleAWTComponent è una classe o interfaccia interna a Component?
    Dalla documentazione javadoc:

    protected abstract class Component.AccessibleAWTComponent
    extends AccessibleContext
    implements Serializable, AccessibleComponent

    Quindi è una "inner" class di Component.
  • Re: Classi ed interfacce

    Supponiamo che Component non sia abstract bensì concreta e che AccessibleAWTComponent sia un'interfaccia. Premesso che Component non può riscrivere i metodi dell'interfaccia innestata (giusto?), credo sia corretto dire:
    - se creo una istanza della classe Component, dovrò riscrivere i metodi dell'interfaccia;
    - se estendo la classe Component, dovrò riscrivere i metodi dell'interfaccia.
    Le cose cambiano se Component può (ma non credo) e riscrive i metodi dell'interfaccia; in tal caso nei due esempi succitati non c'è l'obbligo di fare override.
  • Re: Classi ed interfacce

    Friz02 ha scritto:


    Supponiamo che Component non sia abstract bensì concreta e che AccessibleAWTComponent sia un'interfaccia. Premesso che Component non può riscrivere i metodi dell'interfaccia innestata (giusto?)
    Innanzitutto stai facendo un ragionamento sbagliato. E non tanto perché il tuo scenario (Component concreta) è ipotetico e diverso da quello che realmente c'è nel framework.

    Di per sé non c'è relazione di "ereditarietà" tra una classe e una inner-class contenuta nella classe!
    Se una interfaccia è dentro una classe (cosa perfettamente possibile) non è una "inner-interface". Il termine "inner" si applica alle classi (non interfacce!) che sono membri di una classe e denota una relazione molto particolare tra la istanza della inner-class e la istanza della classe "contenitore".

    Se avessi:
    
    package esempio;
    
    class A {
        interface B {}
    }
    Allora A non ha alcuna relazione di "ereditarietà" con B. B è una (static) nested interface e alla fin fine cambia solo una cosa (rispetto ad avere B fuori): A fa in un certo senso da "namespace" per B, cioè il nome completamente qualificato di B è esempio.A.B , non è solo esempio.B. Si tratta solo di una mera questione di naming.
  • Re: Classi ed interfacce

    Ok...ma allora

    andbin ha scritto:


    Se avessi:

    CODICE: SELEZIONA TUTTO
    package esempio;

    class A {
        interface B {}
    }

    Allora A non ha alcuna relazione di "ereditarietà" con B.
    se A non ha alcuna relazione di ereditarietà con B, cosa succede:
    - se creo una istanza della classe A, dovrò riscrivere i metodi di B?
    - se estendo la classe A, dovrò riscrivere i metodi di B?
    Se non eredito niente di B allora non dovrò riscrivere i suoi metodi...non saprei mi sono perso.
  • Re: Classi ed interfacce

    andbin ha scritto:


    package esempio;
    
    class A {
        interface B {}
    }

    Friz02 ha scritto:


    - se creo una istanza della classe A, dovrò riscrivere i metodi di B?
    - se estendo la classe A, dovrò riscrivere i metodi di B?
    Se non eredito niente di B allora non dovrò riscrivere i suoi metodi...non saprei mi sono perso.
    No, infatti A non ha nulla a che fare con B. A non implementa B (c'è scritto implements B ? ), non ha alcun obbligo nei confronti di B.

    Qui sopra è solo una pura questione di naming. Il nome completamente qualificato di B è: esempio.A.B

    Ma per il resto il comportamento di A non cambia.
  • Re: Classi ed interfacce

    OK.....grazie
  • Re: Classi ed interfacce

    Però se faccio:
    A.B ogg = new A.B(); (.....posso farlo?)
    cambia qualcosa....?
Devi accedere o registrarti per scrivere nel forum
9 risposte