Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1

    Oggetti singleton: piccola precisazione

    Ciao a tutti.
    Ho un dubbio sulle istanze singleton:

    se io creo una classe il cui costruttore setta gli attributi della classe stessa in maniera specifica per chi l'ha creata (ad esempio la classe UserInfo che dato l'user_id setta gli attributi dell'utente) allora NON posso fare oggetti singleton, altrimenti si mischierebbero i dati! Cioè l'utente x potrebbe trovarsi ad utilizzare gli attributi di y (che l'aveva istanziata prima).

    Sbaglio?

  2. #2
    Non sono un genio della OOP, comunque 'a senso', sì, credo di sì.

    Singleton è per condividere una classe in modo comune.

    Di conseguenza, a seconda di come la usi, le proprietà sono disponibili senza istanziare l'oggetto ma ovviamente sono 'condivise' (è una condivisione a livello di Scope del codice PHP comunque, non a livello di esecuzioni del WebServer)

    Nel caso però il codice venga eseguito da utenti diversi e richiami la classe singleton ognuno nel suo codice.... beh credo non ci siano problemi.
    Il singleton riguarderà quella specifica esecuzione di codice e non tutto il portale.
    Quindi se imposti l'id_utente per esempio avrai quell'ID disponibile ovunque nel codice richiamando la singleton, senza dover instanziare l'oggetto Utente.
    Però quei valori saranno impostati ad un certo valore solo in una certa esecuzione del codice.

    Un altro utente si imposterà altri valori su un'altra esecuzione del codice che, anche se c'è un singleton, sarà completamente separata da quella di un altro utente.

    Bisogna vedere come scrivi il codice.

    Ma in linea di massima otterrai le proprietà e i metodi a livello di classe anzichè a livello di oggetto, e non dovrai instanziare niente.
    Ma per due utenti che eseguono separatamente il codice non dovrebbe esserci condivisione di informazioni.

    Disclaimer: questo, se ho capito qualcosa e se non sto dicendo cavolate (com'è probabile)!

    PS - Scusa la logorrea prolissa
    .... e l'estrema ridondanza

  3. #3
    [b]
    Di conseguenza, a seconda di come la usi, le proprietà sono disponibili senza istanziare l'oggetto ma ovviamente sono 'condivise' (è una condivisione a livello di Scope del codice PHP comunque, non a livello di esecuzioni del WebServer)
    Intendevo proprio questo.
    Quindi meglio stare attenti...perché a volte esistono classi i cui attributi sono specifici per l'utente e i metodi richiamano tali attributi, in questo caso creo una nuova istanza allora (che ovviamente è indipendente e 'vive' durante l'esecuzione dello script)

  4. #4
    Attenti sì ma, appunto, è a livello di codice la visibilità, non di esecuzione/sessione sul web server.

    Di fatto due client diversi che eseguono la pagina ottengono valori diversi (o comunque distinti).

    Diverso è se fai due richiami alla stessa classe singleton, nello stesso listato di codice, per due utenti diversi.
    Allora sì che qualche problema potrebbe insorgere

  5. #5
    Originariamente inviato da pictor
    Attenti sì ma, appunto, è a livello di codice la visibilità, non di esecuzione/sessione sul web server.

    Di fatto due client diversi che eseguono la pagina ottengono valori diversi (o comunque distinti).

    Diverso è se fai due richiami alla stessa classe singleton, nello stesso listato di codice, per due utenti diversi.
    Allora sì che qualche problema potrebbe insorgere
    allora mi sto confondendo...
    tu dici in pratica che se 2 utenti accedono allo stessa classe singleton nello stesso script il costruttore setta attributi indipendenti (se la classe lo prevedeva ovviamente...) ed i metodi eventualmente chiamati (nello stesso script) riconoscono questa 'indipendenza' degli attributi? Io credo che i metodi se lavorano sugli attributi settati dal costruttore (o da altri metodi) vanno a sovrascrivere i precedenti (proprio per la condivisione di cui parlavi)

  6. #6
    No, forse mi son spiegato male.

    Quel che dico io è che:

    - Utente A si collega a sito.com/script.php e richiama la singleton. Ci fa quello che vuole.
    - Utente B si collega a sito.com/script.php e richiama la singleton. Ci fa quello che vuole.

    In questo caso sono due esecuzioni diverse di script.php, gestite come due connessioni e script separati, dal web server.
    Quindi non si vanno a toccare.
    L'unica eventualità d'interferenza e condivisione di dati è nel caso tu usi qualche funzionalità di memoria condivisa. E allora gli script possono avere delle informazioni in comune. Ma lo devi fare volontariamente, non succede da solo.

    Quel che dico io è se nello stesso script.php esiste un riferimento a più utenti ed usa sempre la stessa classe.
    Tipo
    - SELECT di tutti gli utenti
    - Ciclo FOR che li scorre tutti
    - Per ogni iterazione vado a fare
    Codice PHP:
    Utente::setID($idUtente
    E ad ogni iterazione $idUtente cambia...

    Beh, essendo nello stesso script, essendo la classe universale e non orientata ad una precisa istanza/oggetto, ogni volta andrai a settare sempre la stessa proprietà con un valore diverso..... e rimarrà solo l'ultimo valore impostato.

    Ti torna?

  7. #7
    Ciao,
    il modello di sviluppo singleton implica che lo scope (visibilità) della classe sia a livello applicativo:

    1 applicazione -> 1 istanza singleton.

    Per esempio pensa ad un sito(il mio) che propone degli articoli di programmazione:
    è inutile che ad ogni utente creo un'istanza dell'articolo A che ha letto precedentemente un'altro utente, siccome l'articolo è sempre uguale per tutti gli utenti non ha senso creare una nuova istanza ad ogni utente, basta un'istanza (sempre la stessa) per chiunque si collega e visualizza quel determinato articolo.

    Comunque, guarda caso, ho scritto proprio un articolo a riguardo, lo
    potete trovare qui: http://mirkoagrati.110mb.com/articoli.php?page=Articoli

    Ciao
    Mirko Agrati
    WEB : http://mirkoagrati.110mb.com
    RSS : http://feeds.feedburner.com/MirkoAgratiArticoli

  8. #8
    Ehi, ottimo lavoro. Avessi io le competenze per fare qualcosa del genere

    Comunque non è che l'articolo gli confonderà le idee?.... o comunque, sicuramente a me le ha confuse

    In fondo usi una Singleton disponibile a tutte le sessioni del portale, appoggiandoti sul filesystem, mi pare di capire. E da lì ti fai una bella cache globale utilizzabile da tutti i client.
    Mentre appunto la singleton si limita al livello applicativo di una sessione (globale sì, ma per quella sessione), no?
    Tu appoggiandoti al tuo file "permanent.cache" la rendi universale e disponibile anche tra accessi da parte di client diversi; ma di fatto la singleton resta limitata alla singola sessione, o sbaglio?

    Non vorrei averla imparata male io: se due client si collegano allo stesso script e richiamano una
    Singleton::getInstance();
    non ottengono gli stessi dati, no? Da come la conosco io ogni utente ha una singleton diversa.

    Correggimi se sbaglio...

    Comunque complimenti

  9. #9
    Ciao Pictor,
    grazie mille per i complimenti !

    Comunque quello che dici, come si manifesta in PHP è in parte vero.

    Questo è dovuto al fatto che PHP non mantiene lo stato delle variabili(neanche statiche) tra un pagina e l'altra.

    Infatti come fai a portarti dietro i dati di un utente? Li metti in $_SESSION.

    Ma ciò che risiede nella variabile $_SESSION vive ed è visibile solo a livello di sessione utente,
    quindi tot utenti = tot sessioni => tot dati uguali per ogni sessione.

    Invece,
    con il termine Singleton si da per scontato che viene utilizzato proprio lo stesso dato (quindi anche il stato) per tutte le sessioni utente e questo perchè la sua visibilità è per definizione a livello di applicazione:
    la stessa applicazione server serve tutti gli utenti.

    Il fatto che io la serializzi è necessario per poter conservare il suo stato tra una pagina ed un'altra, che abbia deciso per il filesystem è una mia scelta personale.

    Sicuramente se avessi potuto avrei utilizzato la variabile $_SERVER[], ma il mio fornitore di hosting ha inibito la possibilità di farlo.

    Spero di non averti confuso maggiormente le idee.

    Grazie ancora per lo spunto che mi hai dato per poter cercare di chiarire ulteriormente il mio articolo.

    Buona serata
    Mirko Agrati
    WEB : http://mirkoagrati.110mb.com
    RSS : http://feeds.feedburner.com/MirkoAgratiArticoli

  10. #10
    Originariamente inviato da mirkoagrati
    Ciao Pictor,
    grazie mille per i complimenti !

    CUT

    Invece,
    con il termine Singleton si da per scontato che viene utilizzato proprio lo stesso dato (quindi anche il stato) per tutte le sessioni utente e questo perchè la sua visibilità è per definizione a livello di applicazione:
    la stessa applicazione server serve tutti gli utenti.
    Ecco, questo lo capivo ma lo applicavo solo all'ambito web; dove appunto si ha una separazione per sessione.
    La singleton l'ho studiata di recente e pian piano mi sto buttando nella OOP a livello un pò più pratico (in passato ho solo fatto la teoria in 3° superiore, un pò di java in 4°, per poi tornare alla web-procedurale in 5° ). Però ho ancora tanto da studiare.
    Tanto tra pochi giorni mi butto sul Visual C++ .... sarà un bagno di sangue


    Il fatto che io la serializzi è necessario per poter conservare il suo stato tra una pagina ed un'altra, che abbia deciso per il filesystem è una mia scelta personale.

    Sicuramente se avessi potuto avrei utilizzato la variabile $_SERVER[], ma il mio fornitore di hosting ha inibito la possibilità di farlo.
    Vabbè, hai avuto l'opportunità di creare qualcosa di molto più portabile
    Spero di non averti confuso maggiormente le idee.
    Speranza vana
    Ma è solo la foschia concettuale prima che spunti il sole della conoscienza!
    Grazie ancora per lo spunto che mi hai dato per poter cercare di chiarire ulteriormente il mio articolo.

    Buona serata
    Di niente. Grazie a te che invece mi hai dato degli elementi per capire meglio il modello MVC. Sto pensando di tirar su qualcosa di simile.... anche se non so se avrò il tempo di farmi tutte le classi d' "intermezzo" per la generazione dell' XHTML e separare definitivamente il codice dal contenuto (cosa ottima per la gestione del multilingua).

    Boh.. ieri ho iniziato a studiarmi i template.... chissà cosa ci tiro fuori

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.