Visualizzazione dei risultati da 1 a 10 su 14

Hybrid View

  1. #1
    Utente di HTML.it
    Registrato dal
    Apr 2014
    Messaggi
    76
    Quote Originariamente inviata da andbin Visualizza il messaggio
    codice:
    CSVFileReader<Persona> csvReader = new CSVFileReader<>("persona.csv", new MyPersonaRowDataMapper());
    List<Persona> listaPersona = csvReader.readAll();
    
    ...
    csvReader.close();
    Ok grazie mille tutto abbastanza chiaro, ho solo un dubbio nella parte che ho quotato, si potrebbe anche fare una cos del genere?

    codice:
    CSVFileReader<Persona> csvReader = new CSVFileReader<>(new MyPersonaRowDataMapper());
     //Passo solo il mapper
    
    List<Persona> listaPersona = csvReader.readAll("persona.csv"); 
    //Qui passo il path del file ed all'interno eseguo la file.close()
    
    //In questo modo posso fare tutte le readAll che mi pare con la stessa istanza...
    C'e qualche controindicazione?

    Nel tuo esempio cosa fa la csvReader.close(); un flush/close del file o anche altro?

    __________________________________________________ ____________________________________
    Leggero O.T.
    Una volta appresi tutti i vari concetti dell'"ingegneria del SW":
    - Ereditarieta', polimorfismo, Generici ecc...
    - Reflection (Su questa zoppico ancora un po')
    - Patter Architetturali (MVC, MVVM, ecc...)
    - Design Pattern (GOF, GRASP); High Coesion, Low Coupling, ecc...
    Di cui si trova anche parecchia documentazione, esempi nei vari linguaggi ecc...

    Mi trovo un po' perso nell'integrazione/alternanza/coesistenza/scelta dei vari concetti...

    Conosci buoni libri, link, guide di "Best Practice" per districarsi oltre andare ad "imitazione" di quanto gia' esistente (Librerie, Framework, ecc...)?

    Un'altro grande dubbio e':
    - Le classi statiche (come le variabili globali) sono "il male assoluto" (vabbe forse un po' esagerato, pero' diciamo che bisognerebbe pensare bene se sono indispensabili prima di utilizzarle)
    - al posto delle classi statiche potrei usare dei singleton...
    - ma sembrerebbe che anche i Singleton vadano "razionati" (oltre ad avere problemi in multi-thread se non adeguatamente implementati)
    - Quindi nel caso di utilizzo di metodi di "Utilita'" generale (uguali per molte/tutte le classi o comunque per classi che non avrebbe senso "imparentare") cos'altro si potrebbe usare usare?
    Ultima modifica di Mrk31; 14-06-2016 a 14:24

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    Ok grazie mille tutto abbastanza chiaro, ho solo un dubbio nella parte che ho quotato, si potrebbe anche fare una cos del genere?

    codice:
    CSVFileReader<Persona> csvReader = new CSVFileReader<>(new MyPersonaRowDataMapper());
     //Passo solo il mapper
    
    List<Persona> listaPersona = csvReader.readAll("persona.csv"); 
    //Qui passo il path del file ed all'interno eseguo la file.close()
    
    //In questo modo posso fare tutte le readAll che mi pare con la stessa istanza...
    C'e qualche controindicazione?
    No, nessuna controindicazione. Semplicemente è un "design" differente. In questo modo CSVFileReader diventa banalmente una "strategia" di lettura di un CSV per un certo tipo specifico ma senza sapere a priori su quale file. Vuol anche dire che ad esempio tu puoi passare un oggetto CSVFileReader (chiaramente parametrizzato, se passi un CSVFileReader<Persona> chi lo usa non può pensare di leggere animali o piante ...) ad un metodo che magari sa di dover leggere due file csv ben precisi di cui vuole ad esempio unire insieme gli oggetti Persona dei due file.

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    Nel tuo esempio cosa fa la csvReader.close(); un flush/close del file o anche altro?
    Banalmente un close() sull'oggetto di I/O più esterno che è incapsulato nel CSVFileReader, un BufferedReader ad esempio.
    Ma se usi il design che hai appena detto, il close sarà quindi incapsulato nel readAll, chiaramente.

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    Mi trovo un po' perso nell'integrazione/alternanza/coesistenza/scelta dei vari concetti...

    Conosci buoni libri, link, guide di "Best Practice" per districarsi oltre andare ad "imitazione" di quanto gia' esistente (Librerie, Framework, ecc...)?
    In questo momento non ho link/riferimenti precisi da indicarti.

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    - Le classi statiche (come le variabili globali) sono "il male assoluto" (vabbe forse un po' esagerato, pero' diciamo che bisognerebbe pensare bene se sono indispensabili prima di utilizzarle)
    Una classe "statica" può essere solo "membro" di un'altra classe (è una nested static class). E si usano, non è quello "il male", di per sé.

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    - al posto delle classi statiche potrei usare dei singleton...
    Probabilmente stai confondendo qualcosa .... una nested static class non c'entra nulla direttamente con il pattern "singleton".

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    - ma sembrerebbe che anche i Singleton vadano "razionati" (oltre ad avere problemi in multi-thread se non adeguatamente implementati)
    Sì ma il pattern singleton può avere svariate varianti a livello implementativo. Dipende se l'oggetto va creato subito o in modo lazy, se deve tenere conto della concorrenza (=sincronizzazione) oppure no.

    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    - Quindi nel caso di utilizzo di metodi di "Utilita'" generale (uguali per molte/tutte le classi o comunque per classi che non avrebbe senso "imparentare") cos'altro si potrebbe usare usare?
    Qui non ho ben capito il senso del dubbio. Se una classe ha solo metodi di "utilità" (come es. java.lang.Math o java.util.Collections) ha senso mettere un costruttore privato e poi avere i metodi tutti static.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Utente di HTML.it
    Registrato dal
    Apr 2014
    Messaggi
    76
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Una classe "statica" può essere solo "membro" di un'altra classe (è una nested static class). E si usano, non è quello "il male", di per sé.

    Probabilmente stai confondendo qualcosa .... una nested static class non c'entra nulla direttamente con il pattern "singleton".

    Sì ma il pattern singleton può avere svariate varianti a livello implementativo. Dipende se l'oggetto va creato subito o in modo lazy, se deve tenere conto della concorrenza (=sincronizzazione) oppure no.

    Qui non ho ben capito il senso del dubbio. Se una classe ha solo metodi di "utilità" (come es. java.lang.Math o java.util.Collections) ha senso mettere un costruttore privato e poi avere i metodi tutti static.
    Intendevo che pur essendo due concetti nettamente distinti Singleton e Classe statica si "somigliano":
    - Non sono "istanziabili"
    - l'idea di utilizzo è che molti oggetti possano utilizzare la "stessa istanza" senza passarla come parametro, ma solo importandola
    - vengono utilizzati in modo simile
    es. CalsseStatica.metodo() Singleton.getInstance().metodo();
    La differenza principale è che la classe statica viene inizializzata "Subito ed in ogni caso", mentre il Singleton in modo "Lazy".

    Quindi potrebbero esserci casi in cui entrambi potrebbero essere "sovrapponibili/intercambiabili/entrambiValidi"...
    Ultima modifica di Mrk31; 14-06-2016 a 15:17

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    Intendevo che pur essendo due concetti nettamente distinti Singleton e Classe statica si "somigliano":
    - Non sono "istanziabili"
    - l'idea di utilizzo è che molti oggetti possano utilizzare la "stessa istanza" senza passarla come parametro, ma solo importandola
    - vengono utilizzati in modo simile
    es. CalsseStatica.metodo() Singleton.getInstance().metodo();
    La differenza principale è che la classe statica viene inizializzata "Subito ed in ogni caso", mentre il Singleton in modo "Lazy".

    Quindi potrebbero esserci casi in cui entrambi potrebbero essere "sovrapponibili/intercambiabili/entrambiValidi"...
    No.

    Una classe "static" (ripeto: deve essere "membro" di un'altra classe) PUO' essere istanziata.
    Una nested static class ha gli stessi identici principi (stesse regole, stesso ciclo di vita, ecc...) di una classe "top-level" (non contenuta dentro qualcosa). È semplicemente da vedere come se fosse in un "namespace" che è fatto dalla classe top-level che la contiene.

    codice:
    public class TopLevel {
        // ....
    
        public static class Nested {
            // ....
        }
    }

    Per poterla istanziare dall'esterno devi fare: new TopLevel.Nested()

    Tutto qui. Per il resto cambia nulla come regole e concetti.

    P.S. deduco che hai le idee un po' confuse su questo argomento.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  5. #5
    Utente di HTML.it
    Registrato dal
    Apr 2014
    Messaggi
    76
    Quote Originariamente inviata da andbin Visualizza il messaggio
    No.

    Una classe "static" (ripeto: deve essere "membro" di un'altra classe) PUO' essere istanziata.
    Una nested static class ha gli stessi identici principi (stesse regole, stesso ciclo di vita, ecc...) di una classe "top-level" (non contenuta dentro qualcosa). È semplicemente da vedere come se fosse in un "namespace" che è fatto dalla classe top-level che la contiene.

    codice:
    public class TopLevel {
        // ....
    
        public static class Nested {
            // ....
        }
    }

    Per poterla istanziare dall'esterno devi fare: new TopLevel.Nested()

    Tutto qui. Per il resto cambia nulla come regole e concetti.

    P.S. deduco che hai le idee un po' confuse su questo argomento.
    Probabilmente sono tardo , ma ancora non ci arrivo...

    Mettiamo che debba implementare, per esempio, una classe/libreria per avere una serie di metodi di utilità per la cifratura di stringhe:
    -con classe statica:
    codice:
    public static class HashUtils{
       public static String getMd5(String pwd) {
          //Restituisce la stringa cifrata in md5;
       }
    }
    --> Utilizzo:
    codice:
    String ciphredPwd = HashUtils.getMd5(pwd);
    -con Singleton:
    codice:
    public class HashUtils { 
       private static HashUtils instance = null;
    
       private/protected HashUtils() {}
    
       public static HashUtils getInstance() {
          if(instance == null) {
             instance = new HashUtils();
          }
          return instance;
       }
    
       public String getMd5(String pwd) {
          //Restituisce la stringa cifrata in md5;
       }
    }
    --> Utilizzo:
    codice:
    String ciphredPwd = HashUtils.getInstance().getMd5(pwd);
    L'unica differenza è che con il singleton avrei l'inizializzazione "pigra"...
    Ultima modifica di Mrk31; 14-06-2016 a 16:02

  6. #6
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    codice:
    public static class HashUtils{
       public static String getMd5(String pwd) {
          //Restituisce la stringa cifrata in md5;
       }
    }
    --> Utilizzo:
    codice:
    String ciphredPwd = HashUtils.getMd5(pwd);
    No. Questa classe HashUtils NON può essere "top level". Dovrebbe essere contenuta dentro un'altra classe. E se lo fosse, l'unica cosa (ripeto l'unica) che cambierebbe è a livello di naming, cioè di qualificazione del nome:

    String ciphredPwd = ClasseTopLevel.HashUtils.getMd5(pwd);


    Quote Originariamente inviata da Mrk31 Visualizza il messaggio
    -con Singleton:
    codice:
    public class HashUtils { 
       private static HashUtils instance = null;
    
       private/protected HashUtils() {}
    
       public static HashUtils getInstance() {
          if(instance == null) {
             instance = new HashUtils();
          }
          return instance;
       }
    
       public String getMd5(String pwd) {
          //Restituisce la stringa cifrata in md5;
       }
    }
    --> Utilizzo:
    codice:
    String ciphredPwd = HashUtils.getInstance().getMd5(pwd);
    L'unica differenza è che con il singleton avrei l'inizializzazione "pigra"...
    Ti ripeto che il concetto del pattern "singleton" non c'entra nulla con la differenza tra una classe "top level" e una "nested" (static).
    Ultima modifica di andbin; 14-06-2016 a 16:27
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  7. #7
    Utente di HTML.it
    Registrato dal
    Apr 2014
    Messaggi
    76
    Quote Originariamente inviata da andbin Visualizza il messaggio
    No. Questa classe HashUtils NON puo' essere "top level". Dovrebbe essere contenuta dentro un'altra classe. E se lo fosse, l'unica cosa (ripeto l'unica) che cambierebbe e a livello di naming, cioe' di qualificazione del nome:

    String ciphredPwd = ClasseTopLevel.HashUtils.getMd5(pwd);



    Ti ripeto che il concetto del pattern "singleton" non c'entra nulla con la differenza tra una classe "top level" e una "nested" (static).
    Forse non riesco a spiegarmi bene io....

    Io vorrei generare una mia classe di utilita' per delle mie librerie, in modo analogo ad esempio a Math...

    Quindi con un utilizzo del tipo Math.abs() senza istanziare un oggetto Math...

    Pensavo che fosse giusto che una classe con SOLO metodi statici dovesse essere dichiarata statica, ma mi son guardato la API di Math ed in effetti è una classe non-statica final in modo da non poterla estendere, che contiente SOLO metodi statici...

    A questo punto non capisco perchè non ci sia la "regola" (che non conoscevo) di non avere classi Top Level statiche?
    Se una classe ho SOLO metodi statici può non essere per forza dichiarata statica, anzi se è top-level NON DEVE...perchè?
    A sto punto qual'è l'utilità del modificatore static riferito alle classi?

    Il mio paragone con il singleton era in relazione alla domanda: mi serve un modo per richiamare metodi senza avere un'istanza per ogni classe che la utilizza o dover passare l'istanza a tutte le classi, come posso fare?

    In ogni caso ci sono articoli, libri, ecc... che confrontano classi statiche e Singleton e che propongono il singleton come alternativa all'utilizzo di classi statiche, non è una mia invenzione ...

    P.S. per curiosità ho guardato in .Net la classe Math è invece statica...
    Ultima modifica di Mrk31; 14-06-2016 a 17:06

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 © 2026 vBulletin Solutions, Inc. All rights reserved.