Implementazione file-directory: un file deve possedere un riferimento alla sua dir?

Question

Implementazione file-directory: un file deve possedere un riferimento alla sua dir?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

1

Attualmente sto creando un problema durante la creazione del design del programma, che è esatto come una relazione File-Directory, e per facilitarla, sto usando questo come esempio.

Credo che è usuale, che una Directory ha una collezione del suo File dei casi.
Prendo questo assioma come un pò, mi corregga se questo non è usuale . < br> Ma quando ci sono eventi che si verificano su un file e la directory vuole essere notificata con tali cambiamenti, il file deve avere un riferimento alla sua directory in qualche modo:

A) Il modo diretto:
La classe File ha un riferimento alla sua istanza Directory .
B) Tramite callback / gestione degli eventi:
La classe File ha un riferimento a una funzione della sua istanza Directory .

O

C) Il Directory controlla le proprietà di File in un intervall.
Odio davvero questa 'soluzione' perché penso che non sia male da morire.

Sia (A, B) modi creano un dipendenza circolare (molti svantaggi) e richiedono l' Directory di File per istanziare prima di se stesso, a meno che pigro-Init File s riferimento (dovrei?).

Quindi, come vengono progettate le relazioni tra file e directory? Hanno una dipendenza circolare, un controllo dell'intervallo, usano lazy-init ...?

object-oriented design-patterns patterns-and-practices circular-dependency

posta user3698624 04.03.2016 - 18:53

fonte

4 risposte

Leggi altre domande sui tag object-oriented design-patterns patterns-and-practices circular-dependency

Perché le condizioni di Coffman sono necessarie per il verificarsi di un deadlock? Quanta ottimizzazione dovresti inserire per le configurazioni lente di test di integrazione

score 2 · Answer 1

Hai fatto un'assunzione potenzialmente non valida nel tuo progetto: non è necessariamente vero che esiste una directory unica che contiene un dato file. Un file può esistere ma non essere collegato in nessuna directory (se è stato cancellato ma ha ancora handle aperti, almeno in alcune implementazioni) o può esistere in più directory (se è stato hard-linked).

Sembra anche probabile che oggetti diversi dalle directory possano interessare gli aggiornamenti ai file, quindi perché non usare semplicemente un pattern Observer qui, senza mettere alcun comportamento speciale sul "genitore" del file?

score 1 · Answer 2

But , when there are events occuring on a file, and the directory wants to be notified with those changes, the file has to have a reference to it's directory in some way ...

Non c'è modo di farlo, almeno su nessuno dei sistemi operativi dominanti e persino su molti dei sistemi operativi minori. Ci sono due problemi. Uno è che i file non conoscono la directory a cui appartengono. L'altro problema forse più grande è che su molti sistemi operativi (ad es. Windows, Linux, OSX), un file non può sapere a quale directory appartiene perché un file può appartenere a più directory.

Proprio come esiste una relazione uno-a-molti tra directory e file, può esserci una relazione uno-a-molti tra file e directory. Un file può essere un membro di più directory, grazie a collegamenti hard e soft. I sistemi operativi non mantengono la relazione uno-a-molti tra file e directory.

I file sono in genere cose molto semplici. Sulla maggior parte dei sistemi operativi, non ci sono metadati associati a un file che indica la directory (o le directory) a cui appartiene un file.

Does a a file have to own a reference to it's dir?

Di solito.

score 0 · Answer 3

Nella relazione Directory-File, non è necessario che un file sia a conoscenza di quale Directory appartiene. Se conosciamo (1) la directory root e (2) per ogni directory che contiene altre directory e file, abbiamo una conoscenza sufficiente per costruire un albero di directory.

In pratica segue il pattern di progettazione composito .

score 0 · Answer 4

Nel mondo reale non avresti un tale modello, dato che caricarebbe l'intero file system in memoria semplicemente accedendo a un singolo file o directory.

Piuttosto avresti un "caricamento lento", quindi un oggetto file carica solo genitori o figli quando richiesto. Un oggetto Directory avrebbe un metodo (non una proprietà!) Che restituisce i suoi figli come una raccolta di oggetti File e Directory (solo un livello in profondità) e gli oggetti File e Directory avrebbero un metodo che restituisce la directory padre.

Potresti avere una collezione live di elementi che è stata aggiornata in base alle modifiche nel file system sottostante. Ma non è necessario propagare le modifiche verso l'alto nella gerarchia.