Alternatives au mot-clé de directive "using" en C #?

Question

Je viens juste de regarder un épisode de Bob Martin au NDC où il a déclaré "en utilisant". Les directives en C # en haut d'une page sont mauvaises en raison du couplage étroit qu'elles créent / impliquent entre les composants.

De quelle manière existe-t-il d'utiliser des fichiers .dll externes sans ajouter de référence de projet et d'instruction using?

Je me souviens que la V6 vous permettait de créer un objet à l'aide de la chaîne de ProgId. Je ne suis pas sûre que ce soit la technique que je recherche, mais c'est un exemple de langage qui n'a pas besoin de référence de projet. utiliser une dll.

EDIT: Voici un lien vers la conférence . . Désolé de ne pas avoir la citation ou la minute exacte dans la présentation, je m'en vais de mémoire.

Answer 1

Ce n'est pas l'énoncé d'utilisation lui-même qui est mauvais - c'est si vous en retrouvez trop .

Une instruction telle que using System; est rarement un problème en soi, mais si vous en avez beaucoup (je dirais plus de 3-6, selon celles-ci) dans le même fichier de code , cela pourrait être une indication d'un couplage étroit .

Vous pouvez également appliquer une règle similaire au nombre de références dans un projet lui-même.

La solution au couplage étroit est la programmation aux interfaces et l’injection de dépendance (DI).

La façon dont ProgId de faire les choses que vous pouvez vous rappeler de VB était simplement COM en action. Essentiellement, vous avez utilisé ce ProgId pour obtenir une référence à une instance qui implémentait l'interface souhaitée. L'inconvénient était que cela ne fonctionnait que lorsque l'objet COM était universellement enregistré. Rappelez-vous dll enfer?

Vous pouvez toujours appliquer le même principe en utilisant certains types de DI, mais l'interface est maintenant de type .NET et n'est pas définie dans IDL. Vous avez besoin d'une sorte de conteneur DI pour fournir l'implémentation concrète.

Answer 2

Je pense que Bob Martin fait en réalité référence à la liaison précoce par rapport à la dernière.

Dans .NET, la liaison tardive est possible par réflexion et plus précisément par la classe Activator qui permet de créer un type dans un assembly externe en utilisant un nom de fichier ou un nom d'assembly.

Normalement, les directives d'utilisation (et non l'instruction using) vont de pair avec la référence directe à un assemblage externe. c'est à dire. Vous ajoutez une référence à un assembly, puis des directives using pour éviter de devoir saisir la hiérarchie d'espace de noms complet lorsque vous utilisez les types externes.

Ainsi, si votre code contient un grand nombre de directives d’utilisation, il est possible que vous référeniez directement de nombreux autres types et augmentiez ainsi le couplage / la dépendance de votre code sur ces types.

Je suppose que c'est la raison pour laquelle Bob se réfère à eux comme étant mauvais. La réponse à la question "est-ce vraiment mauvais?" est très subjectif et dépend du contexte.

Cependant, en général, le découplage des composants est presque toujours un objectif à atteindre lors de la conception de logiciels. En effet, cela vous permet de modifier des parties de votre système avec un impact minimal sur le reste du système. Ayant lu un ou deux livres de Bob Martins, je suppose que c'est ce à quoi il veut en venir.

Answer 3

utiliser n'est qu'un raccourci vers les espaces de noms, ils ne font pas référence à des fichiers externes. Par conséquent, cela n’a pas vraiment de sens.

Quoi qu'il en soit, vous pouvez créer une DLL d'interface (une DLL avec uniquement des interfaces), de manière à charger et utiliser de manière dynamique différents assemblys et à créer des types (par réflexion) que vous pouvez transtyper vers les interfaces connues. C’est le bon moyen de relâcher les références externes tout en conservant les avantages du langage fortement typé et de la liaison anticipée.

Consultez le Assembly et classes AppDomain pour charger des assemblys et Activator pour créer des instances de type par nom.

Answer 4

Vous pouvez utiliser la réflexion:

// Load the assembly
Assembly assembly = Assembly.LoadFrom(@"c:\path\Tools.dll");
// Select a type
Type type = assembly.GetType("Tools.Utility");
// invoke a method on this type
type.InvokeMember("SomeMethod", BindingFlags.Static, null, null, new object[0]);

Answer 5

Vous pouvez faire ce que vous entendez par réflexion. Vous pouvez charger l'assembly au moment de l'exécution et y réfléchir pour obtenir les classes, etc. et les appeler de manière dynamique.

Personnellement, je ne le ferais pas pour éviter le couplage. Pour moi, c’est un mauvais usage de la réflexion, et je préférerais l’ajouter au projet et le référencer, à moins qu’il n’y ait une raison précise pour ne pas le faire. Reflection ajoute une surcharge au système et vous n’obtenez pas l’avantage de la sécurité du temps de compilation.