Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Objets

17 réponses
Avatar
cppnews
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.

--
puff

10 réponses

1 2
Avatar
Jean-Marc Bourguet
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

Avatar
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



Avatar
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

Avatar
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


Avatar
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

Avatar
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 ?


Tu peux utiliser un variant récursif.

typedef boost::make_recursive_variant<
std::string,
std::vector<boost::recursive_variant_>
::type string_tree_t;


Avatar
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.

Sylvain.

Avatar
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.


Avatar
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

Avatar
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



1 2