Je me trouve souvent dans une situation où je répète deux, trois lignes de code dans une méthode plusieurs fois, puis je pense que je devrais mettre cela dans une méthode distincte pour éviter la duplication de code. Mais ensuite, lorsque je déplace ces lignes hors de la méthode, je constate que la méthode vient de créer n'est pas réutilisable, n'a été utilisée qu'une seule fois ou nécessite une surcharge pour être utile pour une autre méthode.
Ma question est de savoir quel type de motifs devrions-nous rechercher cela indiquant que nous devrions créer une nouvelle méthode. J'apprécie votre réponse.
6 Réponses :
En règle générale, pensez toujours à ces situations comme entités fonctionnelles. Si un morceau de code effectue fonctionnellement une tâche (conversion de chaîne complexe, analyse, etc.), vous devez écrire une méthode réutilisable. Si cette fonction est spécifique à un certain type, écrivez un Méthode d'extension .
Vous pouvez créer une variable locale dans votre fonction de type action <> ou FUNC <> et attribuez à l'extrait de code à celui-ci. Ensuite, vous pouvez l'utiliser partout dans votre fonction sans polluer votre classe avec trop de petites fonctions d'assistance.
Si les lignes de code que vous avez l'intention de passer à une autre méthode effectuent un ensemble d'actions spécifiques (comme lire un fichier, calculez une valeur, etc.), il est préférable de refracteur dans une autre méthode d'assistance. Encore une fois, ce n'est que si la méthode d'assistance est appelée à plusieurs endroits de votre code ou si la méthode de votre appelant est trop longue (la définition de Questions similaires
trop long dépend du développeur).
Je commencerais par lire sur le principe sec (ne vous répétez pas vous-même), espérons-le, cela vous donnera une bonne réponse à votre question, qui pose une question à laquelle tous les développeurs devraient se demander à la manière de la façon, une excellente question !!
voir Ne vous répétez pas
Je voulais le laisser au sec parce que c'est un concept aussi simple mais puissant qui aura besoin d'une lecture et de beaucoup de pratique pour obtenir un bon ajout. Mais laissez-moi essayer de répondre directement à votre question (IMHO),
Si vous ne pouvez pas donner à votre méthode un nom qui reflète exactement ce que votre méthode fait, rompez-la en morceaux qui ont une signification.
Vous vous retrouverez à sécher votre code avec facilité, des pièces réutilisables apparaîtront et vous ne vous retrouverez probablement jamais à répéter du code.
Je ferais cela même si cela signifiait avoir des méthodes avec seulement quelques lignes de code.
Suite à cette pratique donnera une signification à votre code, le rendra lisible et prévisible , et définitivement plus réutilisable
Merci Bassam, j'ai acheté le livre dans le lien que vous avez fourni et que vous le lisez. Bien que j'ai lu beaucoup de théorie mais manquez d'application.
@Abdulwaheed J'ai ajouté plus de détails à ma réponse, j'espère que cela répond à certaines de vos questions.
Ne mettez pas trop de fonctionnalité dans une méthode / classe. Essayez de suivre le Principe de responsabilité unique . Cela prendra du temps à se familiariser avec cette approche. Mais une fois que vous atteignez ce niveau, vous remarquerez que cela est fait tout seul. Avant de coder, essayez de vous demander, quelles unités fonctionnelles votre concept comprend votre concept.
Par exemple, vous souhaitez développer une application, qui peut indiquer le contenu des fichiers PDF. C'est juste fictif, mais à première vue, je pourrais identifier au moins trois composants:
référentiel.get (nom de fichier) ou quelque chose
Vous devez également essayer de coder contre des interfaces. Surtout quand une certaine assurance-interface utilisateur est impliquée. Par exemple, vous développez un client de discussion avec Winforms. Si vous suivez le MVC / MVVM -Pattern, vous pouvez facilement (c'est-à-dire plus facile que codage contre un formulaire Objet) Utilisez votre logique d'origine avec une version WPF du client.
Si vous construisez une méthode de réutilisabilité, mais ne l'utilisez pas dans plus d'un endroit, la réutilisabilité de votre méthode n'est pas vraiment vérifiée. Extraire des méthodes lorsqu'il est logique et redessine ces méthodes de réutilisabilité lorsque vous avez la possibilité de réutiliser le code.