Quali altri motivi ci sono per scrivere interfacce piuttosto che classi astratte? [duplicare]

Question

Quali altri motivi ci sono per scrivere interfacce piuttosto che classi astratte? [duplicare]

#1 da (4 voti)
#2 da (1 voti)

1

Quando leggevo e guardavo i codici usando le classi astratte, ero in grado di giustificarlo perché ti permette di aggiungere metodi comuni per qualsiasi sottoclasse che estende la classe astratta. Quindi, per esempio, se il comportamento degli oggetti è simile, userei le classi Abstract per implementare metodi astratti senza corpo che sono richiesti per ogni oggetto, e semplicemente usare metodi non astratti già implementati nella classe astratta. Posso pensare a uno scenario che si occupa di più tipi di file multimediali (avi, mpg, mp4) e avresti metodi comuni per tutti i file, oltre a metodi astratti specifici dei media che devono essere implementati.

Tuttavia, sono un po 'confuso sul motivo per cui si dovrebbe creare consapevolmente un'interfaccia che non può contenere metodi non astratti. Leggendo questa pagina , si afferma che nasconde informazioni (intendi i metodi astratti?).

Hiding details and providing common interfaces is called encapsulation, which is an analogy from making an object look like it's covered by a capsule (the interface in this case). This allows two objects differing in internal representation but having the common interface interchangeably usable (called interchangeability). Interfaces also allow to facilitate the use of data structure and guard the state of the object from invalid inputs and modification of the structure.

Quindi questo significa che qualsiasi oggetto che condivide i comportamenti comuni implementati in modo univoco può essere trattato come se fossero la stessa categoria? Quindi, per l'esempio del file multimediale, vuol dire che qualsiasi tipo di file multimediale specifico che implementa interface MediaFile deve essere passato come argomento per un metodo che riguarda questo tipo di oggetti?

public class ServiceClass {
    public ServiceClass(){
    //no-args constructor   
    }

    public boolean runService(ICollaborator collaborator){
    if("success".equals(collaborator.executeJob())){
        return true;
    }
    else
    {
        return false;
    }
}
}

Ma non puoi fare sopra con una classe astratta? Inoltre, non è la capacità di avere un metodo non astratto meglio di non averne affatto per il futuro quando improvvisamente hai bisogno di un metodo esistente che si applichi a tutte le classi che estendono la classe astratta?

O la differenza nell'uso di Interface, la capacità di proteggere completamente l'implementazione dei dati? Ancora una volta, non vedo in quali casi lo useresti. Oltre a questo, implemento spesso ActionListener quiet per avere il metodo actionPerformed .

java interfaces abstract-class

posta javastudent 08.01.2012 - 13:27

fonte

2 risposte

1

Le interfacce vengono utilizzate in situazioni in cui l'oggetto non ha importanza solo se ha una determinata interfaccia definita. Ad esempio:

function (Interface Object)
{
    // Use a method defined in Interface.
    Object.Method();
}

Quindi possiamo passare qualsiasi oggetto a questa funzione sapendo che tutti gli oggetti (qualunque essi siano) hanno l'interfaccia definita, quindi siamo sicuri di usare quei metodi.

Maggiori informazioni qui: link

risposta data 08.01.2012 - 13:45

fonte

Leggi altre domande sui tag java interfaces abstract-class

Quali lingue parlate dovrei provare a supportare nella mia applicazione Android? [chiuso] Licenza (s) giusta per un'offerta freemium

score 4 · Accepted Answer

Per farla breve, (poiché questa domanda per qualche motivo non viene chiusa), le interfacce sono essenziali per i linguaggi di ereditarietà come Java e C # perché è l'unico modo in cui è possibile aggregare comportamenti diversi in un singolo classe.

In altre parole, quando scrivi una classe A che si aspetta di passare un riferimento ad una cosa B con cui lavorare, aiuta se dichiari che B è un'interfaccia e non una classe astratta, perché se è una classe allora costringerai l'autore della classe C che vuole scrivere C in modo che funzioni con la tua A per derivare la loro classe dalla classe B, mentre potrebbero avere altri piani per essa, il che potrebbe richiedere che C derivi da qualche altra classe D, di cui potresti non aver mai sentito parlare. Scrivendo A in modo che accetti un'interfaccia di tipo B invece di una classe astratta B, l'autore di C è libero di derivare la sua classe da D e implementare anche l'interfaccia B per il lavoro con la classe A.