Objets

Le
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 ç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.
Merci.

--
puff
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Marc Bourguet
Le #303338
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

cppnews
Le #303337
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
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
Le #304103
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
Le #304102
"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.)


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
Le #304101
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

Mathias Gaunard
Le #304100
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;


Sylvain
Le #304099
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.

Laurent Deniau
Le #304098
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.


Loïc Joly
Le #303923
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
Le #303918
On Mar 6, 9:48 am, 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.


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



Publicité
Poster une réponse
Anonyme