2017-10-05 2 views
1

J'ai une question concernant la structure de mon code et comment garder les classes simples. Je travaille sur la simplification de la couche de service d'un projet C#. Une grande partie du code n'a pas pris en compte les pratiques de POO et il y a peu de classes avec des méthodes de plus de 200 lignes. J'ai commencé à extraire des méthodes plus petites, mais j'ai une question rapide sur la façon de le faire. Par exemple, j'ai une méthode qui récupère les répertoires de fichiers qui sont spécifiques à un client, puis vérifie s'ils existent, les crée s'ils ne le font pas et retourne finalement un objet avec une liste de ces répertoires. Je veux garder le principe de ne pas avoir de méthodes privées et extraire dans de nouvelles classes bien que traditionnelles j'aurais créé des méthodes privées pour vérifier si les répertoires existent, un autre pour les créer, un troisième pour récupérer les noms de dossier et retourner l'objet méthode publique pour appeler tous ces éléments dans l'ordre avec une interface associée avec une seule méthode.Couche de service et classes de simplification

Devrais-je créer de nouvelles classes pour chacune de ces méthodes privées et si oui, auraient-elles toutes besoin d'une interface? ou peut-être les garder tous publics et les appeler d'ailleurs?

Merci d'avance!

+0

Je suspecte que cette question sera fermée. Peu importe, voici comment je l'approche: Dans les applications avec un stockage de fichiers dédié, j'ai tendance à faire une classe 'StorageManager', qui est responsable de servir chaque chemin de fichier que je souhaite utiliser. Il est configuré de manière à ce que tout chemin de fichier renvoyé soit automatiquement créé s'il n'existe pas. Si vous avez plusieurs stockages (avec des structures de dossiers différentes), j'ai tendance à hériter de 'StorageManager' et à surcharger la génération du chemin. Je ne suis pas sûr que ce soit objectivement le meilleur moyen, mais je trouve que c'est une approche propre. – Flater

Répondre

1

Réponse courte: vous ne devriez faire aucune de ces choses.

Si vous voulez aborder le problème d'un point de vue orienté objet, oubliez un instant ce que font les méthodes. Pensez à ce que le code est sur. Vous avez seulement mentionné "Client" comme une chose "business" possible. Essayez de trouver d'autres choses pertinentes pour votre entreprise. Quels sont ces fichiers? Rapports? ActivityLogs? Messages? CreditReports :)?

Le fait est que l'orientation objet ne consiste pas simplement à avoir des méthodes dans différentes classes. Les classes et les méthodes doivent avoir une signification commerciale. S'ils ne veulent rien dire, alors il n'y a aucune raison réelle de les avoir en premier lieu! De là, il est également clair que "StorageManager", "StorageUtil", et des choses comme ça ne devrait pas exister, car il n'a aucune signification commerciale du tout. Alors commencez par trouver ce que l'application est à propos de (les choses), puis vous pouvez déplacer certaines responsabilités à la bonne chose.

+0

Merci pour la réponse. Cela m'a fait regarder le programme d'un point de vue différent. Je peux appliquer la logique d'entreprise à cela car je traite des fichiers de commande. Donc, si je devais avoir une classe qui se rapporte au traitement des fichiers de commande, serait-il préférable d'utiliser des méthodes privées ou de créer de nouvelles classes qui se préoccupent d'une partie du traitement des fichiers de commande. Enfin, ceux-ci nécessiteraient également des Interfaces ..... je suppose que tout dans les couches de dépôt et de service devrait avoir des interfaces. – Boggot