Comment devrait-on structurer leurs fonctions non importantes fréquemment utilisées (conversions, etc.) en C# puisque tout doit être contenu dans un objet? Habituellement, je prends toutes ces fonctions et les place dans une classe utilitaire statique. Est-ce une bonne pratique? Comment la plupart des développeurs le font-ils?Fonctions fréquentes: comment structurer?
Cela a tendance à être ce que la plupart des développeurs finissent par faire moi-même. Le seul piège est lorsque vous commencez à avoir un ensemble massif d'utilitaires qui ne devraient pas vraiment tous ensemble (conversion, accès à la base de données, la connexion que vous nommez ...). Essayez de les structurer en différents assemblages, de sorte que les projets qui n'ont pas besoin d'un ensemble d'utilitaires n'auront pas à importer un grand nombre de codes superflus.
Une méthode élégante pour faire cela en C# utilise les méthodes d'extension (Link). Vous pouvez ensuite importer uniquement l'espace de noms correspondant si vous avez besoin de vos fonctions utilitaires. Sur le plan technique, il s'agit essentiellement d'une classe d'utilitaire statique telle que vous l'avez décrite, mais en C# vous obtenez un bon sucre syntaxique pour les utiliser.
Pas un vote négatif, mais la réponse ne répond pas à la question de l'OP sur la façon de structurer leurs méthodes d'utilité. Peut-être pourriez-vous fournir des exemples de la façon dont vous structurez vos méthodes d'extension? –
Désolé mais je pensais que cela est évident lors de l'utilisation des méthodes d'extension. Chaque méthode d'extension étend le type avec lequel la méthode utilitaire doit être utilisée. La structure supplémentaire est la plupart du temps hors de propos avec des extensions. Selon le nombre, vous pouvez les organiser une classe par classe étendue ou une classe pour toutes les méthodes d'extension. – Foxfire
En fonction du besoin particulier, j'utiliserai normalement une structure statique ou un fournisseur de services enregistré. Par exemple, pour la journalisation, j'utilise normalement un fournisseur de services et une classe de journalisation avec un type d'interface ou de logger de base, puis en mode dev je vais enregistrer un fournisseur de boîte de message afin que je puisse voir toutes les lignes connectées niveau de journalisation particulier, tandis que pour obtenir un prédicat List.find particulier pour une liste d'objets, je construis une classe d'utilitaires qui a une méthode statique qui renvoie une classe de prédicat appropriée au type.
Je seconde la notion d'utiliser des méthodes d'extension pour cela. J'ai généralement des classes, dans un espace de noms .Extensions, comme StringExtensions, IEnumerableExtensions, etc. Fondamentalement, j'essaie de créer une classe distincte pour chaque regroupement logique de fonctionnalités. Normalement, cela signifie que je les regroupe en fonction du type qu'ils étendent, du type qu'ils produisent ou de la fonctionnalité globale qu'ils prennent en charge (conversion, formatage, etc.).
Cette réponse n'est pas digne d'une "réponse" réelle mais oui, c'est ce que j'ai tendance à faire aussi. Je ne vois rien de mal à cela; Je ne suis pas sûr qu'il existe un modèle de conception qui ne serait pas exagéré pour une méthode générique que je veux utiliser à plusieurs endroits différents. –