Programmazione Java

di il
13 risposte

Programmazione Java

Ciao a TUTTI ... spero di essere nella giusta locazione del forum.
Scusate se le mie domande saranno banali ma portate pazienza sto solo ora avvicinandomi al linguaggio java ...per me ancora ostico !
Vi chiedo, tralasciano la corretta sintassi che riesco a trovare nei vari manuali che circolano nelle librerie o in internet, di rispondermi
singolarmente ed in modo "terra terra" ai seguenti quesiti .
Ringrazio sin d'ora la community !!!

Perchè e quando è utile e/o consigliato utilizzare una INNER CLASS ?
Perchè e quando è utile e/o consigliato utilizzare un ANONYMOUS INNER CLASS ?
Perchè e quando è utile e/o consigliato utilizzare una ABSTRACT CLASS ?
Perchè e quando è utile e/o consigliato utilizzare una LAMBDA EXPRESSION ?

Ciao a tutti

13 Risposte

  • Re: Programmazione Java

    paolo1960cla ha scritto:


    Perchè e quando è utile e/o consigliato utilizzare una INNER CLASS ?
    Perchè e quando è utile e/o consigliato utilizzare un ANONYMOUS INNER CLASS ?
    Il discorso è quasi uguale. Una classe "innestata", che sia regular, anonymous, local oppure una (static) nested class, è in generale un tipo definito dentro un altro tipo. I motivi potrebbero essere vari. Spesso si usano per nascondere implementazioni di classi in modo che non siano visibili direttamente dall'esterno della classe "contenitore". Le anonymous inner class poi siccome il nome della classe non lo sai, servono principalmente per una sola cosa: ridefinire uno o più metodi di una classe o implementare tutti i metodi di una interfaccia. Non puoi definire metodi nuovi perché appunto essendo la classe sconosciuta, nessuno potrebbe usarli.

    paolo1960cla ha scritto:


    Perchè e quando è utile e/o consigliato utilizzare una ABSTRACT CLASS ?
    Una classe la si definisce "astratta" quando non ha senso che venga istanziata. Tipicamente è perché la classe rappresenta un concetto molto generico o astratto. In una gerarchia per definire oggetti "solidi", ci potrebbe essere una classe base Solido e poi sotto-classi come Sfera, Cubo ecc... Solido essendo un concetto generale, non ha senso che sia istanziato. new Solido() ... solido di che cosa?? Quindi la classe Solido è assolutamente candidata ad essere marcata abstract !
    Una classe astratta quindi deve essere estesa per poter fare qualcosa di concreto.

    paolo1960cla ha scritto:


    Perchè e quando è utile e/o consigliato utilizzare una LAMBDA EXPRESSION ?
    Serve per definire una funzione "anonima" che ha (eventualmente) parametri e un valore di ritorno in modo molto compatto.
    Vedi la http://www.lambdafaq.or di Maurice Naftalin


    P.S. le tue domande richiederebbero risposte almeno 10 volte più lunghe.
  • Re: Programmazione Java

    Grazie molte... in poche righe sei stato esaustivo.
    Mi hai dati buoni spunti sui quali riflettere.
  • Re: Programmazione Java

    Ciao a TUTTI...altra "domandona" : Perchè scegliere di sviluppare un progetto MAVEN e non un progetto "normale" Java Project ?
    Cosa mi fornisce in più MAVEN oltre le piccole differenze di struttura ?
    Grazie
  • Re: Programmazione Java

    paolo1960cla ha scritto:


    Cosa mi fornisce in più MAVEN oltre le piccole differenze di struttura ?
    Principalmente la gestione di tutte le dipendenze dirette e transitive in modo automatico. E inoltre la procedura di build è "standard" perché il ciclo di vita del build si basa su fasi ben precise che comprendono tutto da una validazione iniziale fino ad un deploy finale.
  • Re: Programmazione Java

    Ciao e grazie ma porta pazienza la mia limitata conoscenza....
    cosa significa "dipendenze dirette e transitive in modo automatico" ?
    Su quali fasi si passa il built del progetto (per me il buid è la compilazione) ?
    Mi fai qualche esempio per capire meglio ?
    Grazie
  • Re: Programmazione Java

    paolo1960cla ha scritto:


    Ciao e grazie ma porta pazienza la mia limitata conoscenza....
    cosa significa "dipendenze dirette e transitive in modo automatico" ?
    Su quali fasi si passa il built del progetto (per me il buid è la compilazione) ?
    Ti suggerisco un qualche tutorial/guida su Maven, vedi le risorse ufficiali: http://maven.apache.org/guides

    paolo1960cla ha scritto:


    Mi fai qualche esempio per capire meglio ?
    Hai Maven installato? Metti un file pom.xml dove vuoi (qualunque directory) che contiene:
    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
        <modelVersion>4.0.0</modelVersion>
    
        <groupId>com.esempio</groupId>
        <artifactId>prova</artifactId>
        <version>1.0.0</version>
        <packaging>jar</packaging>
    
        <dependencies>
            <dependency>
                <groupId>org.apache.pdfbox</groupId>
                <artifactId>pdfbox</artifactId>
                <version>1.8.11</version>
            </dependency>
        </dependencies>
    
    </project>
    La Apache PDFBox è una libreria Java per generare e manipolare documenti PDF abbastanza a basso livello. Questa è una dipendenza principale, è elencata nel pom.

    Ora, nella directory dove hai questo pom.xml dai il comando:

    mvn dependency:tree

    Maven scaricherà un po' di cose nel suo repository locale (su Windows si trova in es. C:\Users\nomeutente\.m2 ) e verso la fine ti dirà
    [INFO] com.esempio:prova:jar:1.0.0
    [INFO] \- org.apache.pdfbox:pdfbox:jar:1.8.11:compile
    [INFO]    +- org.apache.pdfbox:fontbox:jar:1.8.11:compile
    [INFO]    +- org.apache.pdfbox:jempbox:jar:1.8.11:compile
    [INFO]    \- commons-logging:commons-logging:jar:1.1.1:compile
    La applicazione quindi avrà 4 dipendenze, una diretta e 3 transitive. Tutti questi jar li ha scaricati Maven nel suo repository locale e li rende disponibili "in classpath" durante il build. Non devi fare nulla di particolare in tal caso.
  • Re: Programmazione Java

    Ok, ho capito. Un buon esempio !
  • Re: Programmazione Java

    Ciao a TUTTI, più vado avanti con lo studio più la nebbia si alza nel mio cervello....
    Vi allego uno schemino (fatto da me quindi sopportate gli errori) chiedendovi cosa c'è che non va o che va relativamente male
    Grazie della collaborazione (ma qui più leggo e peggio va....quindi per cortesia non mandatemi su un'altro tutorial)
    Allegati:
    Schema Riassuntivo Classi ecc.
    Schema Riassuntivo Classi ecc.
  • Re: Programmazione Java

    paolo1960cla ha scritto:


    Vi allego uno schemino (fatto da me quindi sopportate gli errori) chiedendovi cosa c'è che non va o che va relativamente male
    Ho dato una occhiata veloce allo schemino .... ehm .. tra i NO e SI ce ne sono svariati errati/dubbi. Oggi pomeriggio vedo di scriverti qualcosa qui per chiarirti le idee.
    La nebbia al momento è molta, vedo ..
  • Re: Programmazione Java

    Grazie... attendo e rincaro la dose con una serie di regole che ho provato a darmi
    • La classe dovrà essere definita ABSTRACT CLASS qualora sia mia intenzione definire i metodi in @override o ereditare i metodi in .super
    • Una ABSTRACT CLASS non si implementa (implements) ma si estende (exstends).
    • ABSTRACT CLASS NON deve essere Istanzata
    • La ABSTRACT CLASS è riconoscibile dalla keyword “abstract”
    • Una ANONYMOUS INNER CLASS è solo implementazione (implements) di qualcos’altro infatti non avendo un nome, non può definire nuovi metodi;
    • La classe che vuole EREDITARE le proprietà ed i metodi definiti in un’altra classe, dovrà estendere (extends) la stessa classe. Con extends è
    possibile sia ridefinire i metodi (@override) oppure ereditare i metodi (super);
    • La classe “Regular” può essere estesa (extends)
    • Una ANONYMOUS CLASS, non avendo un proprio nome, NON può essere estesa.
    • Una ABSTRACT CLASS NON deve obbligatoriamente estendere (extends) una Interfaccia e NON deve obbligatoriamente implementare
    (implements) una Interfaccia , NON deve obbligatoriamente eseguire override (@override) ne eseguire ereditare (super)
    • La ABSTRACT CLASS, che non è completa, ha SEMPRE un nome contrariamente alla Anonymous Class o ad una Anonymous Inner Class
    • Una ABSTRACT CLASS può, ma non necessariamente, avere METODI ASTRATTI
    • Solo le Proprietà ed i Metodi Statici di una qualunque Classe o Interfaccia sono visibili SENZA implementare la Classe o Interfaccia che li contiene
    • Le Classi definite STATIC presentano Proprietà e Metodi che sono visibili dalla altre Classi del Progetto anche se la Classe NON viene Istanzata
  • Re: Programmazione Java

    Partiamo da alcune basi, forse le sai già ... o forse no.

    In Java i tipi sono in due grosse categorie: primitivi e reference. Tralasciamo i primitivi, i tipi reference sono principalmente tre: classi, interfacce e array.
    Da Java 5 si aggiungono anche: enumerazioni (un tipo molto particolare di classe) e le annotazioni (un tipo molto particolare di interfaccia).

    Sugli array non c'è molto (ora) da dire: sono tipi che NON definisci tu, sono intrinseci del linguaggio. Quando definisci una variabile int[][] matrice; stai usando un tipo int[][] che è già noto al linguaggio. Non devi definire nulla in tal senso. Gli array non li definisci, non li estendi, non ne cambi il comportamento. In sostanza, li puoi solo usare.

    Quindi le entità che tu puoi effettivamente creare sono di:
    - class
    - interface
    - enum (enumerazione)
    - @interface (annotazione)

    Questi tipi li puoi definire "innestati" o no. Quando non sono innestati, li si definisce tipi "top level" (sentirai sovente questo termine), ad indicare che il tipo NON è definito lessicalmente dentro un altro tipo.

    Un tipo top level può avere solamente 2 livelli di accesso: public o "default" (= a livello di package). In pratica o metti la parola chiave "public" o non la metti. Non ci sono altre possibilità per il livello di accesso.
    I tipi "innestati" invece essendo membri di un altro tipo che fa da contenitore, possono avere gli stessi livelli di accesso che hanno anche i metodi: "default", private, protected o public.


    Visto che dallo schemino che hai postato sono evidenti dei dubbi sulle classi, ecco un po' di cose sulle classi.

    Una classe la PUOI istanziare SE: non è astratta ed ha un costruttore accessibile. Bisogna sempre prima vedere la accessibilità della classe e poi la accessibilità di costruttori/membri.
    Se una classe è pubblica ma c'è un unico costruttore privato, tu dall'esterno non potrai istanziarla. Solo dall'interno sarà istanziabile. In questo caso la classe è "visibile" ma non lo è il costruttore dall'esterno.
    In modo un po' diverso, una classe con livello "default" nel package X NON è accessibile da un package Y. Se già la classe non è accessibile (=visibile), non lo sono neanche i membri e i costruttori, anche se fossero public.

    Se la classe è abstract, allora è "astratta", quindi:
    - NON la puoi istanziare.
    - la DEVI (dovresti, perlomeno per buon senso) estendere per fare qualcosa di concreto. L'obiettivo di una classe astratta è quello appunto di essere estesa.

    Una interfaccia è come se fosse, concettualmente, una classe astratta al 100%, cioè non c'è nulla di concreto (dimentichiamo un momento le novità di Java 8 sulle interfacce ). E nota, NON ha alcun costruttore, quindi una interfaccia NON è istanziabile.
    Inoltre una interfaccia NON "implementa" altre interfacce. Invece una interfaccia può estendere altre interfacce (e nota: anche più di una, per le interfacce la ereditarietà è "multipla").

    Nel tuo schemino parli di "Static Class" dicendo "Quando voglio rendere visibili proprietà o metodi ad altre classi del progetto senza bisogno di istanziare la classe".
    Attenzione: una classe che ha solo campi o metodi static, NON è una Static Class !! Non ha un nome particolare questa forma (non in Java perlomeno).
    Una classe ha sempre e comunque almeno 1 costruttore. Se una classe ha solo campi/metodi static, un costruttore lo ha comunque, potrebbe essere accessibile dall'esterno oppure no.
    Certo ... se ha SOLO campi/metodi statici, non ha molto senso istanziarla ... gli oggetti non hanno "stato" (=variabili di istanza) e quindi non servirebbe a molto. Se una classe offre solo metodi statici di "utilità", tipicamente si fa in modo che abbia un costruttore privato, così nessun programmatore avrebbe la tentazione di istanziarla, visto che non avrebbe senso.


    Passiamo ai tipi "innestati". Come ho detto prima sono tipi definiti lessicalmente dentro un altro tipo. Attenzione a non vedere la cosa in modo parziale/limitato. Il tipo innestato può essere qualunque dei tipi detti prima anche differente dal tipo contenitore, quindi in realtà puoi fare molte combinazioni anche "strane" es.:
    - una classe dentro una interfaccia
    - una interfaccia dentro una classe
    - una enum dentro una classe
    - una annotazione dentro una enum
    - una interfaccia dentro una interfaccia
    ecc...

    I tipi detti genericamente "innestati" in realtà sono da dividere in due categorie:
    - "inner"
    e
    - "nested"

    Sfortunatamente, in inglese "inner" e "nested" sono termini abbastanza sinonimi, perlomeno danno entrambi l'idea di qualcosa che è contenuto dentro qualcos'altro. In Java sono due cose DIVERSE.

    Una inner class è un tipo dichiarato SENZA la parola "static", ed è contenuto dentro un altro tipo.
    Una nested class è un tipo dichiarato CON la parola "static", ed è contenuto dentro un altro tipo.

    La caratteristica principale delle inner class è che una istanza della inner class è sempre associata ad una ben precisa istanza della classe contenitore (esiste una eccezione). Ed esiste una "relazione" molto particolare tra le due classi.
    Con una nested (e meglio dire anche "static") class invece NON esiste questa relazione particolare con la classe contenitore. Il tipo che fa da contenitore va visto più banalmente come se fosse un "namespace" in più per arrivare alla nested class.

    Le "inner" class sono definibili in 3 forme:
    - una forma in cui la inner class è un membro diretto della classe, questa è chiamata solitamente "regular" inner class, giusto solo per distinguerla dalle altre due forme.
    - una forma in cui la inner class è dichiarata dentro un BLOCCO di codice (si chiama "local" inner class).
    - una forma in cui la dichiarazione e la istanziazione coincidono, questa è la "anonymous" inner class, che ha la caratteristica di poter solo: a) estendere 1 classe O b) implementare 1 interfaccia. E il nome della classe anonima è appunto sconosciuto a priori.

    Le "nested" (static!) class sono semplicemente tipi dichiarati con la parola chiave "static" come membri di un altro tipo.


    Per il momento credo di aver detto molto e so già che quanto detto ti porterà sicuramente ad avere molti altri dubbi/domande. Per il momento vediamo cosa ti è chiaro. Adesso vedo di rispondere anche ai punti che hai aggiunto dopo.
  • Re: Programmazione Java

    paolo1960cla ha scritto:


    • La classe dovrà essere definita ABSTRACT CLASS qualora sia mia intenzione definire i metodi in @override o ereditare i metodi in .super
    NO. Ridefinire un metodo lo puoi fare indipendentemente dal fatto che la classe corrente o la super-classe siano astratte oppure no. È ovvio che se la super-classe è astratta e la sotto-classe è "concreta" (non astratta), allora la sotto-classe per forza di cose dovrà fornire una implementazione per tutti i metodi che sono ancora astratti nella super-classe.

    Riguardo l'uso della annotazione @Override è semplicemente un aiuto a livello di compilazione (non è obbligatorio usarla). Se un metodo è marcato @Override, il compilatore si assicurerà che il metodo faccia davvero un override, altrimenti lo segnala come errore.

    La invocazione di una versione "super" di un metodo la puoi sempre fare ... a patto che la versione del metodo nel super tipo sia accessibile e "concreta".

    paolo1960cla ha scritto:


    • Una ABSTRACT CLASS non si implementa (implements) ma si estende (exstends).
    Ok

    paolo1960cla ha scritto:


    • ABSTRACT CLASS NON deve essere Istanzata
    Sì, vero, "non può" essere istanziata.

    paolo1960cla ha scritto:


    • La ABSTRACT CLASS è riconoscibile dalla keyword “abstract”

    paolo1960cla ha scritto:


    • Una ANONYMOUS INNER CLASS è solo implementazione (implements) di qualcos’altro infatti non avendo un nome, non può definire nuovi metodi;
    NO.
    Una anonymous inner class può solo fare UNA di queste due cose:
    a) estendere 1 classe
    oppure
    b) implementare 1 interfaccia (estendendo implicitamente Object)

    Una anonymous inner class PUO' definire metodi "nuovi", ad esempio metodi privati ad uso interno dei metodi in override. Può anche definirli public ... ma tanto non saranno usabili, il nome della classe non lo sai e quindi NON avrai variabili del tipo della anonymous inner class e quindi i metodi nuovi, anche se pubblici, non li potresti invocare.

    paolo1960cla ha scritto:


    • La classe che vuole EREDITARE le proprietà ed i metodi definiti in un’altra classe, dovrà estendere (extends) la stessa classe. Con extends è possibile sia ridefinire i metodi (@override) oppure ereditare i metodi (super);
    Un po' impreciso. "extends" mette in atto la "ereditarietà", quindi una classe B che estende A, eredita i membri (quelli accessibili!) di A ed ha facoltà (o obbligo se sono abstract e la sotto classe è concreta) di ridefinire quei metodi accessibili che non sono final.

    paolo1960cla ha scritto:


    • La classe “Regular” può essere estesa (extends)
    Non è chiaro cosa intendi per "regular". Comunque una classe in generale si può estendere se tutte le seguenti condizioni esistono:
    - è accessibile (dalla classe che vuole estenderla)
    - non è final
    - ha un costruttore accessibile.

    Una classe "final" NON è estendibile.

    paolo1960cla ha scritto:


    • Una ANONYMOUS CLASS, non avendo un proprio nome, NON può essere estesa.
    Vero. E dirò di più: una anonymous inner class è IMPLICITAMENTE final !

    paolo1960cla ha scritto:


    • Una ABSTRACT CLASS NON deve obbligatoriamente estendere (extends) una Interfaccia e NON deve obbligatoriamente implementare (implements) una Interfaccia , NON deve obbligatoriamente eseguire override (@override) ne eseguire ereditare (super)
    Ok, vero. Se una classe è astratta NON ha alcun obbligo di rendere "concreti" tutti (o certi) i metodi.

    paolo1960cla ha scritto:


    • La ABSTRACT CLASS, che non è completa, ha SEMPRE un nome contrariamente alla Anonymous Class o ad una Anonymous Inner Class
    Qui è vago. Tutte le classi hanno SEMPRE un nome, ANCHE le anonymous inner class. Solo che per le anonymous inner class il nome è generato dal compilatore e quindi non è direttamente noto/deducibile nel sorgente e dal programmatore.

    paolo1960cla ha scritto:


    • Una ABSTRACT CLASS può, ma non necessariamente, avere METODI ASTRATTI
    Vero. Una classe può essere abstract e avere solo metodi concreti. Ovviamente ci dovrà essere un motivo per questo ....

    paolo1960cla ha scritto:


    • Solo le Proprietà ed i Metodi Statici di una qualunque Classe o Interfaccia sono visibili SENZA implementare la Classe o Interfaccia che li contiene
    Detto un po' male ma in sostanza i membri statici esistono (e sono usabili) indipendentemente dalle istanze del tipo che li contiene. Tieni presente che le interfacce NON possono avere metodi statici, questo fino a Java 7. Da Java 8 le interfacce possono avere metodi di "default" e metodi "statici".

    paolo1960cla ha scritto:


    • Le Classi definite STATIC presentano Proprietà e Metodi che sono visibili dalla altre Classi del Progetto anche se la Classe NON viene Istanzata
    Una classe NON è "Static" perché ha solo metodi/campi static. In Java il termine "static class" NON ha senso a meno che ti riferisci alle nested (static) class.
  • Re: Programmazione Java

    Innanzitutto GRAZIE
    Ora non mi resta che riflettere attentamente su ogni singola affermazione e correggere il tiro
Devi accedere o registrarti per scrivere nel forum
13 risposte