Les classes doivent-elles forcément être liées ?

Bonjour,

Dans le but de me perfectionner dans les technos que j'apprécie particulièrement, je compte programmer plusieurs petits logiciels qui me permettront d'être plus performant en programmation.

Je comptais attaquer par un petit programme tout simple, qui se contente de faire des sauvegardes sur FTP d'un ou plusieurs répertoires à des heures précises. Je pourrais programmer ça en quelques heures, mais je voudrais que ça soit "propre".

Je voulais commencer le diagramme de classe, mais je me rends compte que mes classes vont toutes être plus ou moins "indépendantes" les unes des autres. Je risque d'avoir une classe "Compression", une classe "Sauvegarde", une classe "SendFTP" etc... J'ai l'habitude de faire des applis qui travaillent avec une BDD, et le diagramme de classe comporte donc des relations. Mais là, rien...

Donc, ma question est probablement stupide, mais ça me fait bizarre de travailler avec des classes sans aucune liaison entre elles : est-ce possible de faire ça ou est-ce moi qui n'ai pas compris quelque chose ?



PS : Je sais que ce n'est pas vraiment le bon forum pour ça, mais en parlant de code "propre", je comptais implémenter l'archi MVC. Je code en C# sous VS2008 et je voudrais être sur que :
Modèle = les fichiers MaClasse.cs, contenant les classes, structures...
Vue = Les fichiers .Designer.cs
Contrôleur = les fichiers MaForm.cs contenant les events

Merci :)

Citation:

---

Envoyé par Ikki_2504

Donc, ma question est probablement stupide, mais ça me fait bizarre de travailler avec des classes sans aucune liaison entre elles : est-ce possible de faire ça ou est-ce moi qui n'ai pas compris quelque chose ?

---

Par définition une conception OO c'est des instances de classes qui collaborent entre elles pour réaliser quelque chose. Toi tu n'as que des classes seules pour réaliser quelque chose ? Alors soit oui tu as un problème de conception OO soit tu modélises dans un seul diagramme des classes qui entre elles n'ont rien à voir car ne s'occupe pas du tout du même domaine.

Citation:

---

PS : Je sais que ce n'est pas vraiment le bon forum pour ça, mais en parlant de code "propre", je comptais implémenter l'archi MVC. Je code en C# sous VS2008 et je voudrais être sur que :
Modèle = les fichiers MaClasse.cs, contenant les classes, structures...
Vue = Les fichiers .Designer.cs
Contrôleur = les fichiers MaForm.cs contenant les events

---

Non ce n'est pas du tout cela.

Vue = MaForm.cs + les fichiers Designer.

Modèle : tes .cs qui ne sont pas des formes ni des contrôleurs.

Contrôleur : c'est ce qui fait le lien entre le système et/ou les vues et ton modèle

Citation:

---

Par définition une conception OO c'est des instances de classes qui collaborent entre elles pour réaliser quelque chose. Toi tu n'as que des classes seules pour réaliser quelque chose ? Alors soit oui tu as un problème de conception OO soit tu modélises dans un seul diagramme des classes qui entre elles n'ont rien à voir car ne s'occupe pas du tout du même domaine.

---

Le logiciel doit juste faire des sauvegardes de répertoires à heures régulières, donc comme je le disais dans mon 1er message, je vois bien une classe pour les méthodes de compression, une pour les envois de fichiers sur FTP etc. Mais je vois pas vraiment de relations entres elles comme je ferai dans un logiciel de gestion d'auto-école par exemple...

Citation:

---

Vue = MaForm.cs + les fichiers Designer.
Modèle : tes .cs qui ne sont pas des formes ni des contrôleurs.
Contrôleur : c'est ce qui fait le lien entre le système et/ou les vues et ton modèle

---

Ça me paraît en effet plus logique...
Pour la vue et le modèle je crois que j'ai compris.
Pour le contrôleur... J'ai encore un peu de mal. Ce doit bien être un fichier séparé ? Y a t-il des conventions de nommage, et si oui, lesquelles ?
Enfin, dans ce fichier contrôleur, y a t-il autre chose à mettre que les abonnements aux events (qui interagiront avec le modèle) ?

Merci :)

Citation:

---

Envoyé par Ikki_2504

Le logiciel doit juste faire des sauvegardes de répertoires à heures régulières, donc comme je le disais dans mon 1er message, je vois bien une classe pour les méthodes de compression, une pour les envois de fichiers sur FTP etc. Mais je vois pas vraiment de relations entres elles comme je ferai dans un logiciel de gestion d'auto-école par exemple...

---

A partir de ton énoncé voilà grossomodo un code possible (je te laisse faire la rétro-ingénierie avec un outil UML)

Ce que je veux dire c'est qu'on peut y voir des associations, cela dépend de l'analyse/conception faite sur le sujet énoncé il faut donc se rappeler qu'une conception oo c'est des objets qui collabore ensemble pour faire un job ;)


J'utilise le langage C# pour illustrer ce concept. On pourrait faire ressortir de nouvelles classes pour par exemple la compression ou la distribution. Par exemple la distribution comment l'étendre pour utiliser non pas qu'un seul protocole comme ftp mais aussi inclure le http ou autre ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public class Compresseur { public bytes []Compresser(string NomRepertoire) {} } public class Distributeur { public void DistribuerParFtp(bytes[] datas){}; } pubic class ControleurSauvegarde { public void Process() while(true) { if(TimeToProcess) { Compression sr = new Compression(); byte[] datas = sr.Compresser(NomRepertoire); new Distributeur().DistrbuerParFtp(datas); } } } }

---

Le contrôleur c'est un pattern qui réponds à la question à qui envoyer un message venant d'une IHM ? La réponse est à une classe contrôleur sauf que toi tu n'as pas d'IHM il faut donc regarder du côté de ce qui se rapproche du pattern contrôleur pour ton cas et cela pourrai être bien une facade mais il faut en dire plus sur la technologie et architecture de ton projet

Citation:

---

Le contrôleur c'est un pattern qui réponds à la question à qui envoyer un message venant d'une IHM ? La réponse est à une classe contrôleur sauf que toi tu n'as pas d'IHM il faut donc regarder du côté de ce qui se rapproche du pattern contrôleur pour ton cas et cela pourrai être bien une façade mais il faut en dire plus sur la technologie et architecture de ton projet

---

Si, j'ai bien une IHM, je fais ce projet en WindowsForm.
Donc mon contrôleur reçoit des actions de la vue et "passe la main" à une classe Modèle ?

Par exemple dans ma vue, je pourrai avoir :

Code:

---

1 2 3 4 5

private void button1_Click(object sender, EventArgs e) { ControlleurSauvegarde.Sauvegarder(); }

---

et une classe ControlleurSauvegarde dans ce genre :

Code:

---

1 2 3 4 5 6 7 8 9

pubic class ControleurSauvegarde { public void Sauvegarder() { Compression sr = new Compression(); byte[] datas = sr.Compresser(NomRepertoire); new Distributeur().DistrbuerParFtp(datas); }

---

Les classes Compression et Distributeur étant définies dans des fichiers séparés.

Ça respecterait le modèle MVC ?

oui.

Ok, merci de m'avoir aidé, je commence à mieux comprendre :ccool: