Visualizzazione dei risultati da 1 a 5 su 5

Discussione: Interface & abstract

  1. #1
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157

    Interface & abstract

    Sintatticamente questa classe non dà problemi (tutto compila ed esegue correttamente), mi chiedo semanticamente quanto senso abbia ribadire l'astrazione....qualche delucidazione??
    codice:
    public interface MyInterface{
        public abstract void metodo1(); 
        public abstract void metodo2(Param1 param1); 
    }

  2. #2
    Utente di HTML.it L'avatar di Alex'87
    Registrato dal
    Aug 2001
    residenza
    Verona
    Messaggi
    5,802

    Re: Interface & abstract

    Un metodo in una interfaccia non può non essere astratto quindi si può fare a meno di specificarlo (in quanto appunto non è possibile dichiararlo in modo differente).

    Scrivere quindi

    codice:
    public interface MyInterface {
        public abstract void metodo1(); 
        public abstract void metodo2(Param1 param1); 
    }
    o scrivere

    codice:
    public interface MyInterface {
        void metodo1(); 
        void metodo2(Param1 param1); 
    }
    è esattamente la stessa cosa.
    SpringSource Certified Spring Professional | Pivotal Certified Enterprise Integration Specialist
    Di questo libro e degli altri (blog personale di recensioni libri) | ​NO M.P. TECNICI

  3. #3
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    sisi infatti io ho chiaro questa cosa, però trovandolo in codice (non scritto da me) che compila ed esegue correttamente mi sono chiesta: non è che c'è qualche motivo, a me ignoto, per cui ha senso fare questa doppia affermazione?

    Almeno noto che non sembra strano solo a me

  4. #4
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,326
    Originariamente inviato da valia
    sisi infatti io ho chiaro questa cosa, però trovandolo in codice (non scritto da me) che compila ed esegue correttamente mi sono chiesta: non è che c'è qualche motivo, a me ignoto, per cui ha senso fare questa doppia affermazione?

    Almeno noto che non sembra strano solo a me
    Credo che sia, appunto, un modo per dare maggiore chiarezza (o per avere subito sott'occhio il fatto che si tratti di metodi astratti).

    Sto pensando ad un (quantomai improbabile) ambito in cui una persona debba guardare velocemente il codice di diverse classi: se la persona passa da una interfaccia ad una serie di classi in maniera veloce per tutto il giorno può capitare che ad un certo punto non si renda perfettamente conto che sta guardando il codice di una interface... rimarcare il fatto che quei metodi siano abstract (lecito, quanto inutile siamo tutti d'accordo), può facilitare...

    Boh... ho finito gli specchi.

    C'è da dire che io, solitamente, non specifico "abstract" per i metodi di interfaccia, ma specifico comunque "public" (anch'esso del tutto inutile), solo per una forma di coerenza con me stesso.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

  5. #5
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Per me la spiegazione può essere che quella prima era una classe astratta e nel passaggio ci si è dimenticati di cancellare gli abstract, il mio specchio è un po' più realistico del tuo, ma specchio è e specchio resta.



    Pensavo che questo errore semantico generesse un warning (specie con l'IDE), ma niente (o forse io non lo vedo perché li ho disabilitati quasi tutti)vabbé, alla fine la mia curiosità è soddisfatta, ho tolto gli abstract e continua ad andare tutto bene

    Grazie a tutti e due e buon pomeriggio

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.