Visualizzazione dei risultati da 1 a 6 su 6

Visualizzazione discussione

  1. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da rick.card82 Visualizza il messaggio
    mi sto avvicinando a Java, e tra le varie cose mi sono imbattuto nelle classi astratte ed interfacce. A grandi linee ho capito come lavorano, ma non riesco a capirne l'utilità, o meglio, se comunque da queste va derivata una classe concreta che implementa i metodi definiti nell'astratta, tanto vale creare una classe ex-novo completa di metodi necessari etc senza derivarla da un'altra, oppure mi sfugge qualcosa / il vantaggio di derivare da una classe astratta o interfaccia ?
    Innanzitutto quando vedi la parola "abstract" (su classi o metodi) devi pensare a qualcosa di "incompleto". Perché qualcosa dovrebbe poter non essere completo ... beh, questo è un discorso un po' più ampio che ti sarà più chiaro con una visione più estesa sulla programmazione ad oggetti.

    La OOP consente due cose importanti: riutilizzo del codice ed estensione/specializzazione del codice altrui. Nei linguaggi non object-oriented (es. "C") è facilissimo riusare funzioni (anche fatte da altri) ma è estremamente difficile (se non impossibile) estendere e soprattutto "specializzare" codice altrui. In OOP invece è possibile e banale grazie al meccanismo della ereditarietà.

    Ma nella OOP bisogna cercare quindi di pensare in termini di tipi che sono correlati tra di loro secondo una relazione di generalizzazione/specializzazione. Un Veicolo ha certe caratteristiche e certi comportamenti. Una Automobile la deriviamo da Veicolo, poiché saprà fare tutto ciò che Veicolo sa fare, magari con qualche operazione implementata diversamente ("specializzazione") o magari con qualcos'altro in più. Una Ferrari la deriviamo da Automobile perché anche qui farà tutto ciò che sa fare Automobile con qualcosa di meglio o in più. E così via.

    La questione di classi astratte e interfacce è per fornire degli elementi di "astrazione", per rappresentare entità più generiche o tipicamente non concrete. Spesso faccio questo esempio basilare: una gerarchia di classi per rappresentare oggetti "solidi".

    - Classe Solido
    - Classe Cubo che estende Solido
    - Classe Sfera che estende Solido
    ecc...

    Ha senso poter istanziare Solido? Solido che cosa? No, infatti non ha granché senso. Solido è un concetto generale, non qualcosa di reale, concreto che puoi misurare e toccare.
    E in Java (come altri linguaggi ad oggetti) c'è un modo per far sì che Solido possa essere definito come qualcosa di non concreto, appunto una classe "astratta". Che fa sì che la classe NON possa essere istanziata direttamente ma che debba essere estesa in qualche modo più concreto per fare qualcosa di utile e reale.

    Una interfaccia è da vedere concettualmente come una classe astratta al 100% (dimentichiamo per un attimo le novità di Java 8 sulle interfacce). La differenza tra classi astratte e interfacce sta nella ampiezza d'uso, dovuta anche e soprattutto al fatto che in Java una classe può estendere UNA sola classe ma può implementare N interfacce.
    Le interfacce quindi si possono applicare a più classi anche "trasversalmente" in gerarchie differenti. E sovente una interfaccia serve per rappresentare la capacità di saper fare qualcosa.

    Una interfaccia Pesabile che dichiara un double getPeso() potrebbe essere applicata sia alla gerarchia di Veicolo, sia alla gerarchia di Solido (con i dovuti dati necessari). Ma potrebbe anche essere applicata ad una gerarchia che ha alla base la classe Persona.
    Ultima modifica di andbin; 29-11-2016 a 00:44
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

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.