[C#] programmation judicieuse ?

**iamunknown** · 06/02/2006, 17h28

bonjour !

mon programme posséde ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
[Main.cs]
//programmation qui appelle des méthodes de ma classe (voir ci-dessous)
 
[Class1.cs]
Class1
{
collectionX CX = new collectionX();
//méthode qui manipule les données passées en paramètres à partir de Main.cs
exemple : 
- méthode qui me renvoit le count de ma collection... 
- méthode qui ajoute un nouvel élément à ma collection en passant par les classe ci-dessous...etc
}
 
Class2
{
//constructeur + getters qui me renvoi les données contenu dans ma collection
}
 
Class collectionX : System.Collections.CollectionBase
{
//méthode permettant d'ajouter, supprimer un élément de ma collection
}

ma question est donc la suivante :

est-ce judicieux de programmer de cette façon ?

je veux dire par là que le fait de manipuler ma collection dans ma class1 (en recevant les paramètres de mon form principale) puis de basculer tout cela vers mes classe techniques... est-ce correct ?

niveau compilation ça fonctionne... mais niveau "conception orientée objet" ça vaut quelque chose ?

avant d'aller plus loin je préfére savoir

merci !

**NicolasG** · 06/02/2006, 19h48

Si j'ai bien compris, tu as une collection, une classe (class1) pour écrire dedans et une autre (class2) pour lire.

Si class1 et class2 ne font que ça, elle sont inutiles.
Il faut utiliser simplement ta classe collection pour accéder aux données.

**iamunknown** · 06/02/2006, 21h58

ma classe2 contient des données privée qui sont en fait stockés dans ma collection.

et ma classe1 ne fait pas uniquement ça

**NicolasG** · 06/02/2006, 22h09

C'est un peu difficile de donner un avis sans connaître ce que tu veux faire.

**iamunknown** · 07/02/2006, 11h53

en fait je voudrais reprendre une idée de logiciel posé sur le forum... un générateur de cv.

je voudrais donc organiser tout ça correctement dans un premier temps avant de me lancer dans le code

**hobotalker** · 07/02/2006, 16h36

Moi je vote non, pas du tout.

Sauf cas exceptionnels, un membre (ta collection) ne doit etre manipulé que par sa propre classe. Tes Get(), Set() et consorts doivent tous etre dans Classe1.

Le but est justement d'interdire l'acces a ta collection a toutes les autres classes et de pouvoir la manipuler que par les regles que tu auras toi meme definies dans tes methodes.

Euh ... Je suis clair, là?

**iamunknown** · 07/02/2006, 16h42

salut hobotalker ! oui c'est très clair ce que tu as évoqué

alors comment organiserais-tu ça ? une ébauche... pour moi pas partir dans le décor

merci !

**hobotalker** · 07/02/2006, 16h51

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Classe1
{
private MaCollectionX objCollection = new CollectionX();
public void AjouterElement();
public void SupprimerElement(int iIndex);
public int NbElements
{
    get { return objCollection.Count; }
}
 
// etc etc ...
 
}

Désolé, moi j'suis plutot C# ...

**NicolasG** · 07/02/2006, 17h03

Je pense qu'il est préférable d'étendre les fonctionalités de CollectionX plutôt que de créer une autre classe pour l'encapsuler.

**iamunknown** · 07/02/2006, 18h02

ah il est préférable de tout mettre dans classe1...

oui je suis plutot C# aussi

donc je ne distingue rien.. je manipule tout au sein de la même classe...

si c'est confirmé je commence ! lol

a vos marques... prêt... confirmez ?

**Piotrek** · 08/02/2006, 02h00

Salut

Moi je raisonne autrement:

Tant que j'ai deux possibilites de faire la meme chose de deux manieres differentes, mais apparement justes, je me pose des questions jusqu'a ce que je puisse me dire qu'un des moyens est meilleur que les autres.

Comme je ne connais pas les tenants et aboutissants du programme, je te dis: je suis incapable de repondre

Il faut donc que tu te pose les bonnes questions:

- Quel est l'objectif (unique si possible) de chaque classe
- Qui apelle quoi, qui a besoin de quoi
- Faut il un intermediaire pour que cette classe ne depende pas directement de celle-ci
- Qu'est ce qui pourrait etre modifie dans le futur (ou comment faire pour que tout ne se casse pas la figure plus tard si je modifie quelque chose, ou si je rajoute une alternative)
......

Prends le temps de bien reflechir au role que jouent tes classes, meme si elles ont l'air inutiles maintenant, demande-toi pourquoi tu as voulu les mettre, decide de les garder, d'en rajouter, ou pas

Bien sur avec la pratique, cette reflexion sera plus naturelle et plus rapide, tu vas acquerir des reflexes. Tu pourras etudier les "best practices" et les desing patterns pour a la fois enrichir ta reflexion , voire pour trouver des solutions toutes faites

**iamunknown** · 08/02/2006, 11h24

salut piotrek !

si je comprends bien, toi tu raisonnes plutot sur les "objectifs" d'une façon générale. Donc rien n'est mauvais, rien n'est "bon" tout dépend ce que l'on attend et désire !

je suis entièrement d'accord avec toi sur ce point. Cependant étant donné que c'est mon premier vrai programme orienté objet, je voulais éviter de foncer droit dans le mur !

donc attendez quelque réflexion possible quand à la structure de mon application.

sachant que je veux faire quelque chose d'assez "classique".
- saisies des formations, expériences, compétences, loisirs et informations civiles. Puis génération d'un cv de façon automatique en récupérant les saisies faites par l'utlisateur. Je veux donner la possibilité à l'utilisateur de sauvegarder son cv saisie, en vue d'une modification ultérieure pour ainsi le regénérer et éviter qu'il ne retape la totalité de son cv.
L'extension de l'application est envisageable... dans le futur.

Pour quel structure d'application obteriez-vous ?

merci !

**_skip** · 08/02/2006, 12h26

Salutations,

Ce que j'en pense moi, si j'ai bien compris:
Ce que tu fais là, c'est que

- tu as une collection
- tu souhaites créer une classe destinée à lire/modifier cette collection
- une autre destinée à ajouter et supprimer un élément de cette collection

Pour mois c'est un peu comme si tu essayais de modéliser un cube avec trois INT pour la longueurs des cotés, et que tu décidais de mettre les méthodes GET/SET dans une autre classe, et les méthodes Perimetre() et volume encore dans une autre!

Question code, il devra y avoir une référence vers cette collection dans chacune des classes qui vont la manipuler! Ce n'est pas grave à priori mais ça deviendra super lourd lorsque cet objet collection devra être supprimé.

Le but de la POO est justement de regrouper dans une enveloppe "une classe en l'occurence" une entité PLUS tout ce qui est nécessaire pour la manipuler. Hors ton idée casse ce concept.

Pour moi, ta collection et ses méthodes de manipulation, ça doit être une seule et même classe.

Donc, tu peux hériter de collection et la compléter selon tes besoins, ou si tu ne veux pas que toutes les méthodes de collection soient accessibles, encapsuler et appauvrir.

Tu m'as suivi?