Bonjour,
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est =E7a fonctionne :)
Les choses deviennent plus compliqu=E9s si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du m=EAme
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
J'espere avoir bien defini mon probleme.
Merci.
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ? J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
cppnews@gmail.com writes:
Bonjour,
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ? J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
cppnews
Si je pose la question autrement, avec quel type d'arbres je pourrai le mieux representer la structeur d'un disk, sachant que chaque repertoire peu imbriqué n sous reperoires et k fichiers ?
Merci.
On 5 mar, 11:41, Jean-Marc Bourguet wrote:
writes:
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ? J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF:http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index .html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si je pose la question autrement, avec quel type d'arbres je pourrai
le mieux representer la structeur d'un disk, sachant que chaque
repertoire peu imbriqué n sous reperoires et k fichiers ?
Merci.
On 5 mar, 11:41, Jean-Marc Bourguet <j...@bourguet.org> wrote:
cppn...@gmail.com writes:
Bonjour,
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF:http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index .html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si je pose la question autrement, avec quel type d'arbres je pourrai le mieux representer la structeur d'un disk, sachant que chaque repertoire peu imbriqué n sous reperoires et k fichiers ?
Merci.
On 5 mar, 11:41, Jean-Marc Bourguet wrote:
writes:
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
Pourquoi des pointeurs?
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ? J'espere avoir bien defini mon probleme.
Le resultat est un arbre. Comment est-ce que tu stockes un arbre?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF:http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index .html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Etienne Rousee
a écrit ...
Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ?
Google te dira tout sur le design pattern "composite".
--
Etienne
<cppnews@gmail.com> a écrit ...
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
Google te dira tout sur le design pattern "composite".
Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ?
Google te dira tout sur le design pattern "composite".
--
Etienne
Jean-Marc Bourguet
"James Kanze" writes:
On Mar 5, 10:58 am, wrote:
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Il est aussi possible d'avoir un Directory qui contient des Directory et des File sans y accéder par la même interface.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"James Kanze" <james.kanze@gmail.com> writes:
On Mar 5, 10:58 am, cppn...@gmail.com wrote:
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou
bien tu t'arranges que File et Directory aient le même type
(avec probablement une attribute qui disent lequel c'est, et un
tableau de descendants, qui serait vide dans le cas des
fichiers), ou bien, tu fais dériver les deux d'un type commun,
et tu en fais des tableaux des pointeurs au type de base. (Le
type Directory en contiendra un tel tableau ; le type File
non.)
Il est aussi possible d'avoir un Directory qui contient des Directory et
des File sans y accéder par la même interface.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Il est aussi possible d'avoir un Directory qui contient des Directory et des File sans y accéder par la même interface.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
On Mar 5, 10:58 am, wrote:
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
-- James Kanze (Gabi Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 5, 10:58 am, cppn...@gmail.com wrote:
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou
bien tu t'arranges que File et Directory aient le même type
(avec probablement une attribute qui disent lequel c'est, et un
tableau de descendants, qui serait vide dans le cas des
fichiers), ou bien, tu fais dériver les deux d'un type commun,
et tu en fais des tableaux des pointeurs au type de base. (Le
type Directory en contiendra un tel tableau ; le type File
non.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
-- James Kanze (Gabi Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Mathias Gaunard
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ?
Bonjour,
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
Bonjour, - Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi) Y'a t il des patterns dans ce sens ?
Il est aussi possible d'avoir un Directory qui contient des Directory et des File sans y accéder par la même interface.
je pense qu'on préfère en effet les énumérer séparément (sans n'interdit pas une interface commune). une des raisons est l'énumération des répertoires de même rang (sibling vs childs), celle-ci est sûrement gérée au niveau du parent commun (n-1) qui donnera à itérateur sur les rep. de niveau n, un tel itérateur n'énumererait que les rep. - et non les files qui seront des childs purs d'un rép.
pour des fichiers, comme pour une liste à n niveaux, le pattern unique n'existe peut être pas.
Sylvain.
Jean-Marc Bourguet wrote on 05/03/2007 20:17:
Il est aussi possible d'avoir un Directory qui contient des Directory et
des File sans y accéder par la même interface.
je pense qu'on préfère en effet les énumérer séparément (sans n'interdit
pas une interface commune).
une des raisons est l'énumération des répertoires de même rang (sibling
vs childs), celle-ci est sûrement gérée au niveau du parent commun (n-1)
qui donnera à itérateur sur les rep. de niveau n, un tel itérateur
n'énumererait que les rep. - et non les files qui seront des childs purs
d'un rép.
pour des fichiers, comme pour une liste à n niveaux, le pattern unique
n'existe peut être pas.
Il est aussi possible d'avoir un Directory qui contient des Directory et des File sans y accéder par la même interface.
je pense qu'on préfère en effet les énumérer séparément (sans n'interdit pas une interface commune). une des raisons est l'énumération des répertoires de même rang (sibling vs childs), celle-ci est sûrement gérée au niveau du parent commun (n-1) qui donnera à itérateur sur les rep. de niveau n, un tel itérateur n'énumererait que les rep. - et non les files qui seront des childs purs d'un rép.
pour des fichiers, comme pour une liste à n niveaux, le pattern unique n'existe peut être pas.
Sylvain.
Laurent Deniau
James Kanze wrote:
On Mar 5, 10:58 am, wrote:
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
a+, ld.
James Kanze wrote:
On Mar 5, 10:58 am, cppn...@gmail.com wrote:
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou
bien tu t'arranges que File et Directory aient le même type
(avec probablement une attribute qui disent lequel c'est, et un
tableau de descendants, qui serait vide dans le cas des
fichiers), ou bien, tu fais dériver les deux d'un type commun,
et tu en fais des tableaux des pointeurs au type de base. (Le
type Directory en contiendra un tel tableau ; le type File
non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type
Directory qui contient un vector de Directory et un vector de File.
Directory fourni deux iterateurs, l'un sur les directories et l'autre
sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger
les deux types.
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
a+, ld.
Loïc Joly
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
Parce qu'il peut y avoir des opération que l'on souhaite faire à tous les éléments, comme par exemple effacer, modifier des droits d'accès, obtenir un nom... Ca peut me sembler légitime.
-- Loïc
Pourquoi compliquer les choses? Un type File d'un cote et un type
Directory qui contient un vector de Directory et un vector de File.
Directory fourni deux iterateurs, l'un sur les directories et l'autre
sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger
les deux types.
Parce qu'il peut y avoir des opération que l'on souhaite faire à tous
les éléments, comme par exemple effacer, modifier des droits d'accès,
obtenir un nom... Ca peut me sembler légitime.
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
Parce qu'il peut y avoir des opération que l'on souhaite faire à tous les éléments, comme par exemple effacer, modifier des droits d'accès, obtenir un nom... Ca peut me sembler légitime.
-- Loïc
James Kanze
On Mar 6, 9:48 am, Laurent Deniau wrote:
James Kanze wrote:
On Mar 5, 10:58 am, wrote:
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
Parce qu'ils sont melangés. Un répertoire peut contenir indifféremment des fichiers ordinaires ou des répertoires (ou parfois d'autres choses) ; un « nom de ficher » peut en fait soit désigner un répertoire ou un fichier ordinaire, soit ne pas exister, pour savoir lequel.
Dans mon cas, par exemple, j'ai un type File pour les tous ; mon abstraction, c'est plutôt celui d'un nom de fichier, que d'un répertoire ou d'un fichier en soi, mais la classe a bien des fonctions pour se renseigner sur des détails : exists(), isDirectory(), et même list() (avec la précondition « isDirectory() ». Si je modèlais l'hiérarchie sur disque, le choix serait peut-être différent. (Il serait sans doute plus propre de le nommer FileName, et lui donner une fonction qui renvoie un AbstractFile, qui serait concrétement un OrdinaryFile, un Directory, ou quelque chose du genre, et null s'il n'existe pas. Pour l'instant, j'ai préféré la garder telle quelle, comme type de valeur, copiable, etc., même s'il a de la fonctionalité qui ne convient qu'à certaines instances.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 6, 9:48 am, Laurent Deniau <laurent.den...@cern.ch> wrote:
James Kanze wrote:
On Mar 5, 10:58 am, cppn...@gmail.com wrote:
- Pour construire la list des repertoires ainsi que les fichiers que
contient chacun, avec l'hypothese que chaque repertoire ne peut
contenir que des fichiers, l'implementation la plus simple que j'ai pu
trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le
nom du repertoire
+ Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :)
Les choses deviennent plus compliqués si un repertoire peut contenir
d'autre repertoires, et la soit je change mon design (je seche) ou il
faut que mon objet repertoire doit contenir d'autres objets du même
type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou
bien tu t'arranges que File et Directory aient le même type
(avec probablement une attribute qui disent lequel c'est, et un
tableau de descendants, qui serait vide dans le cas des
fichiers), ou bien, tu fais dériver les deux d'un type commun,
et tu en fais des tableaux des pointeurs au type de base. (Le
type Directory en contiendra un tel tableau ; le type File
non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type
Directory qui contient un vector de Directory et un vector de File.
Directory fourni deux iterateurs, l'un sur les directories et l'autre
sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger
les deux types.
Parce qu'ils sont melangés. Un répertoire peut contenir
indifféremment des fichiers ordinaires ou des répertoires (ou
parfois d'autres choses) ; un « nom de ficher » peut en fait
soit désigner un répertoire ou un fichier ordinaire, soit ne pas
exister, pour savoir lequel.
Dans mon cas, par exemple, j'ai un type File pour les tous ;
mon abstraction, c'est plutôt celui d'un nom de fichier, que
d'un répertoire ou d'un fichier en soi, mais la classe a bien
des fonctions pour se renseigner sur des détails : exists(),
isDirectory(), et même list() (avec la précondition
« isDirectory() ». Si je modèlais l'hiérarchie sur disque, le
choix serait peut-être différent. (Il serait sans doute plus
propre de le nommer FileName, et lui donner une fonction qui
renvoie un AbstractFile, qui serait concrétement un
OrdinaryFile, un Directory, ou quelque chose du genre, et null
s'il n'existe pas. Pour l'instant, j'ai préféré la garder telle
quelle, comme type de valeur, copiable, etc., même s'il a de la
fonctionalité qui ne convient qu'à certaines instances.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
- Pour construire la list des repertoires ainsi que les fichiers que contient chacun, avec l'hypothese que chaque repertoire ne peut contenir que des fichiers, l'implementation la plus simple que j'ai pu trouver est:
+ Un objet repertoire : Attributs vector <string> *listOfFiles, et le nom du repertoire + Un Objet catalog : Atributs vector <reportoire> *listOfDirs.
c'est basic, simple est ça fonctionne :) Les choses deviennent plus compliqués si un repertoire peut contenir d'autre repertoires, et la soit je change mon design (je seche) ou il faut que mon objet repertoire doit contenir d'autres objets du même type (la je seche aussi)
Y'a t il des patterns dans ce sens ?
C'est un arborescence classique. J'en vois deux solutions : ou bien tu t'arranges que File et Directory aient le même type (avec probablement une attribute qui disent lequel c'est, et un tableau de descendants, qui serait vide dans le cas des fichiers), ou bien, tu fais dériver les deux d'un type commun, et tu en fais des tableaux des pointeurs au type de base. (Le type Directory en contiendra un tel tableau ; le type File non.)
Pourquoi compliquer les choses? Un type File d'un cote et un type Directory qui contient un vector de Directory et un vector de File. Directory fourni deux iterateurs, l'un sur les directories et l'autre sur les files. L'interface en sera plus simple comme ceci il me semble.
Je ne vois pas pourquoi ici on devrait faire une hierarchie ou melanger les deux types.
Parce qu'ils sont melangés. Un répertoire peut contenir indifféremment des fichiers ordinaires ou des répertoires (ou parfois d'autres choses) ; un « nom de ficher » peut en fait soit désigner un répertoire ou un fichier ordinaire, soit ne pas exister, pour savoir lequel.
Dans mon cas, par exemple, j'ai un type File pour les tous ; mon abstraction, c'est plutôt celui d'un nom de fichier, que d'un répertoire ou d'un fichier en soi, mais la classe a bien des fonctions pour se renseigner sur des détails : exists(), isDirectory(), et même list() (avec la précondition « isDirectory() ». Si je modèlais l'hiérarchie sur disque, le choix serait peut-être différent. (Il serait sans doute plus propre de le nommer FileName, et lui donner une fonction qui renvoie un AbstractFile, qui serait concrétement un OrdinaryFile, un Directory, ou quelque chose du genre, et null s'il n'existe pas. Pour l'instant, j'ai préféré la garder telle quelle, comme type de valeur, copiable, etc., même s'il a de la fonctionalité qui ne convient qu'à certaines instances.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
