Il 17 maggio 2013 20:25, enrico franchi <enrico.fran...@gmail.com> ha scritto:
> Una oggetto non ragiona in termini di 'intero programma' (a meno che
> la sua semantica non sia proprio di rappresentare il processo).
Sì, questo "credo" di averlo capito.
> Nel
> tuo caso vuoi un oggetto che rappresenta un archivio zip... salvo che
> a naso c'e' gia' fatto nell'appropriata libreria, al piu' ha senso
> lanciare un'eccezione nel costruttore se il file non esiste.
>
è vero che esiste una libreria già fatta, ma nel mio caso devo
trattare solo una tipologia di file (di testo, e che derivano da
un'altra classe), quindi è un "vestito" per rendere evidente l'uso che
devo fare di questo file.
per chiarire un po' la cosa, vi faccio un esempio di come dovrebbe
essere questa classe:
class compresso:
pass
def __init__(self, project):
# Verifico l'esistenza del file passato come argomento.
# altro?
pass
def create(self):
# Creare il file compresso
pass
def exist(self)
# verifico che esista il file compresso.
pass
def add_dizionario(self, dizionario_path):
# inserire il file della classe dizionario nel file compresso
pass
def remove_dizionario(self, dizionario_path):
# estrarre il file della classe dizionario dal file compresso
pass
def exist_dizionario(self, dizionario_path):
# Verificare l'esistenza del file della classe dizionario nel file compresso
pass
def extract_dizionario(self, dizionario_path, destinazione):
# estrarre il file della classe dizionario dal file compresso
pass
def last_dizionario(self)
# fornisce l'ultimo dizionario (in ordine alfabetico).
pass
> Ti invito comunque a riflettere che: se anche il file esiste quando
> istanzi l'oggetto,
oddio... in realtà se sparisce questo file, sparisce l'intero progetto
che sto facendo...
> nulla ti garantisce che continuera' ad esistere quando ci fai sopra le
> operazioni.
se smette si esistere è perché si è corrotto il file system, oppure
root (questo è un file generato e gestito da un processo con i
privilegi di root) è così pazzo da lanciare il mio programma e da
togliergli il classico tappetto da sotto i piedi. sicuramente non può
essere il mio programma a cancellarlo (non è previsto che una volta
creato possa essere cancellato, solo modificato) il mio programma
potrebbe cancellarlo solo se viene attivata la funzione di rollback e
quindi viene cancellato l'intero progetto generato.
> Fallire subito puo' avere senso (a
> patto che poi non assumi che il file sia ancora li). Oppure potresti
> controllare che esiste e prenderti un descrittore di file -- che
> rimane al tuo processo --.
ecco è questo che voglio capire... praticamente quel "self", che cosa
deve diventare? in altre parole, quando istanzio l'oggetto
"compresso", deve tornare qualcosa al programma che lo chiama, e
questo qualcosa viene assegnato ad una variabile. Quando a questa
variabile applico uno dei metodi che ho inserito nella classe, questo
metodo è una funzione che viene eseguita su questa variabile "self".
self dovrebbe (se non ho capito male il discorso delle classi) essere
l'oggetto "compresso" nel suo insieme, quindi un contenitore dove
anche se viene chiamato in tempi diversi dal programma, esistono delle
variabili locali che soppravvivono tra una chiamata e l'altra.
un'operazione che potrebbe fare init, potrebbe essere semplicemente
quella di assegnare ad una variabile interna il nome e il path del
file "compresso", poi la verifica che esista o meno, lo deve fare il
programma chiamante attraverso il metodo exist(self).
il vantaggio che ho in questo modo di usare le classi, è che non devo
ricordarmi ogni volta che nome ha il file compresso, lo identifico una
volta per tutte, e poi ci chiamo sopra i metodi... la classe mi
permette solo di concentrare in un punto logico tutta la gestione di
questo file, gestione che potrebbe essere demandata semplicemente alle
stesse funzioni messe esternamente alla classe, ma con una diversa
logica nella "visione" d'insieme.
Questo è almeno quello che mi pare di aver capito di uno dei modi di
usare le classi, forse non il più ortodosso, ma dovrebbe essere
funzionale nel mio progetto...
> In generale mi viene da dire che piu' simile la semantica del
> costruttore e' ad "aprire il file" e piu' senso abbia lanciare
> eccezione per un file che non esiste. Per un oggetto impostato piu'
> come 'descrizione', lo vedo inappropriato (anzi, potrebbe avere senso
> creare il file solo esplicitamente alla chiamata di un metodo).
sì, credo anche io che convenga che il file compresso sia aperto e
chiuso da ogni metodo che viene chiamato su di esso, per un semplice
motivo, non esisterebbe poi un metodo esplicito che avrebbe il compito
di chiudere il file alla fine di tutto il processo, o meglio, nel
design del programma non avrebbe molto senso esplicitarlo.
Byez
--
Gollum1
Tesssssoro, dov'é il mio tessssoro...
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
