Choix stratégique entre main et classes personnelles

Bonjour tout le monde.
Je suis confronté à ce que j'appèlerais "un dilemme du hérisson".

Actuellement lorsque je travaille sur mon code, j'ai deux choses.

Citation:

---

Form1.java (Mon main en quelque sorte)
GestionProp.java (Ma classe fourre tout)

---

La question que je me pose.
Ne serait-il pas mieux de faire la chose suivante:

Citation:

---

GestionProp
-Crée un fichier
-Modifie un fichier (Ajoute une clé=donnée)
-Modifie un fichier (Met à jours une clé par sa donnée)
-Modifie un fichier (Retire une clé et sa donnée)

GestionRep
-Test le path d'un répertoire
-Test le path d'un répertoire et d'un fichier contenu dans le répertoire
-Crée un répertoire
-Crée un sous répertoire
-Automatise
-Lance un test du path
-Le répertoire n'existe pas, on lancera "Créer un répertoire"
-Le répertoire étant créer
-Lance "Test le path d'un répertoire et d'un fichier contenu dans le répertoire"

---

Et enfin mon main

Citation:

---

-Récupère le path
-Transmet le path à Automatise de GestionRep
-Test à nouveau le path avec le fichier properties
-Le path est bon, on crée un properties
-Transmet le path/Fichier.properties à Crée un fichier de GestionProp
-Suite du programmme

---

Est-ce la bonne solution ou une seule classe doit tout faire par elle même?
J'avoue que c'est plus une question de stratégie que de facilité. Le but étant de ne pas tout re-coder entre une classe et une autre en limitant les dépendances de l'une à l'autre.

Pour ceux qui ont un peu de pratique, j'aimerais avoir votre avis sur le sujet.
Merci beaucoup.

J'ai l'impression que tu raisonnes en fonctionnel et pas du tout en objet.
Il te faut un objet qui gère l'intégralité du fichier de propriétés du point de vue utilisateur. Cet objet se débrouille pour faire sa cuisine, on n'a pas besoin de savoir ce qu'il fait et comment il le fait. Il encapsule les données et les traitements. Libre à toi d'utiliser des sous-objets pour construire cet objet mais ces sous-objets resteront "invisible" aux autres objets qui l'utiliseront.
Tu dois partir d'un schéma générique, avec la définition des méthodes. Peu importe le contenu des méthodes tant que tu connais les signatures et les fonctionnements aux limites. Le corps des méthodes pourra ainsi être développé "dans le bureau d'à côté" sans aucune incidence sur ton propre développement.

Je comprend bien ce que tu me dit la dinobogan.

Mais ce que j'ai du mal à saisir c'est la dépendance entre classe.
Ce qui me donne quelques cas assez précis:

Citation:

---

-Soit je fait un main qui, appelle plusieurs classes, chacune d'elle sachant quoi faire en interne, ceci provoque des doublons dans chaques classes (Ce que je veux a tout prix éviter)

-Soit je fait un main qui, appelle plusieurs classses, chaque classe à son rôle bien déterminé (Ce qui me semble logique mais qui peut, a un moment donné se révélé lourd au niveau du main, car il faudra sans cesse jonglé entre les classes - J'irais plus volontier dans ce sens (et ca n'empêche pas de voir comme chaque objet, ici je parle de facilité de programmation et de compréhension du code))

-Soit je fait un main qui, appelle une classe, qui appelle une autre classe (Ce que je pense pas pratique car il y a des dépendances entre classe, mais on a évité le cafouillage dans le main pour le déplacé ailleurs (La ne parlons plus d'objets mais de chef cuisinier mettant son grain de sel un peu partout!))

---

Ce que j'aimerais c'est voir ce qui se fait de plus propre, en exemple, pour des projets de grande ampleur, avec objet et donc manipulation de classes.

Après ce qui se passe dans une classe, ne me pose aucun problème car j'en ai déjà réalisé par le passé et j'arrive sans problème a les manipulé en tant qu'objets.

Merci.

Je ne suis pas le plus qualifié. Mais je met dans mon main des objets concrets, ceux-ci font appel à des controleurs qui eux font appels a des objets bas niveau.

Bon et bien, ne cherchez plus!
La réponse est en fait bien simple.
Classe 1 -> méthodes indépendantes
Classe 2 -> méthodes indépendantes
Classe 3 -> méthodes pouvant être écrite de façon identique aux deux autres classes
Main -> appel de la classe 3 -> traitement des réponses
Main -> appel de la classe 2 -> traitement 1
Main -> appel de la classe 2 -> traitement 2
Main -> appel de la classe 1 -> traitement 1
etc...

Voila qui résous en partie le problème cité dessus.