séparation du code en C#

Bonjour,
Je débute en C# et j'aimerais avoir une précision concernant une application console créée pour afficher des contacts. Donc, il y'a la class contact.cs et le program.cs. J'aurais aimé savoir ce que doit contenir exactement chaque fichier comme par exemple les propriétés, les méthodes, les objets instanciés, les constructeurs... etc. J'imagine qu'on ne peut pas placer n'importe quoi (par exemple les propriétés ou les méthodes) au choix dans le program.cs ou dans le contact.cs. Chaque chose doit avoir sa place. C'est là où je cale, je me perds dans le va et vient du code entre les 2 fichiers à savoir ce qui doit être placé uniquement dans le program.cs ou dans la class contact.cs pour ne pas tout mélanger.
Ce serait sympa d'avoir une réponse sur cette séparation du code entre les 2.
Merci.

Salut,

Pour commencer (si tu n'as pas déjà parcouru ces liens) :

• http://tahe.developpez.com/dotnet/csharp/
• http://broux.developpez.com/articles...ter-en-dotnet/

Citation:

---

Envoyé par webjoe

J'aurais aimé savoir ce que doit contenir exactement chaque fichier comme par exemple les propriétés, les méthodes, les objets instanciés, les constructeurs...

---

Les méthodes, propriétés sont à définir dans une classe si elles ont un sens 'métier' pour cette classe (objet) que tu es en train de créer.

Tu dois instancier un objet au moment où tu as besoin de l'utiliser, peu importe où au final.

Après avoir lu la définition de ce qu'est un constructeur (voir lien précédent), tu comprendras clairement le sens et la place de ce dernier ;)

Bonne lecture.

Citation:

---

Envoyé par webjoe

J'imagine qu'on ne peut pas placer n'importe quoi (par exemple les propriétés ou les méthodes) au choix dans le program.cs ou dans le contact.cs.

---

Bonjour. Peut-être était-ce mal formulé mais, à tout hasard, le nom du fichier ne t'impose aucune contrainte. Tu peux tout mettre dans un seul fichier, appeler l'un des fichiers "toto.cs", etc. Ce qui compte, c'est moins la séparation physique (dans deux fichiers) que la séparation logique (classes isolées avec des responsabilités restreintes et bien définies).

Maintenant, pour revenir sur le fond. Par affichage des contacts, tu veux dire des personnes physiques ou morales ? Des noms, téléphone, e-mail, etc ? Si oui, alors :
* L'application se contente t-elle de lire depuis un source donnée, d'afficher et de quitter (événetuellement en demandant d'appuyer sur un touche) ? Si oui, les contacts n'ont pas forcément besoin d'être représentés par des objets. Par exemple, si on lit depuis un flux XML, on peut très bien générer l'affichage à la volée sans s'encombrer d'une classe pour un problème aussi petit.
* S'agit-il d'un exercice scolaire ? Si oui, oublie ma précédente remarque, la séparation est imposée je présume.
* Si on souhaite séparer les choses, et bien, contact doit avoir un constructeur depuis la source de données, et exposer les propriétés Nom, Email, etc... Quant à Program, il a la responsabilité d'instancier les contacts puis de les afficher.
* On pourrait aussi déléguer une partie de l'affichage dans contact (surcharge de ToString par exemple : ToString n'envoie rien vers la console mais retourne une chaine que Program enverra vers cette celle-ci). Cela dit, je recommande plutôt de faire de Contact une pur objet métier (business object) et donc de ne pas faire cela.