Pourquoi ne devrait-il pas c # (ou .NET) pour nous permettre de mettre une méthode statique / partagée à l'intérieur d'une interface?
apparemment dupliquer de ICI . Mais mon idée est un peu différente, je veux juste mettre une aide à mes plugins (interface) p>
ne devrait pas c # au moins autoriser cette idée? P>
namespace MycComponent { public interface ITaskPlugin : ITaskInfo { string Description { get; } string MenuTree { get; } string MenuCaption { get; } void ShowTask(Form parentForm); void ShowTask(Form parentForm, Dictionary<string, object> pkColumns); ShowTaskNewDelegate ShowTaskNew { set; get; } ShowTaskOpenDelegate ShowTaskOpen { set; get; } // would not compile with this: public static Dictionary<string, ITaskPlugin> GetPlugins(string directory) { var l = new Dictionary<string, ITaskPlugin>(); foreach (string file in Directory.GetFiles(directory)) { var fileInfo = new FileInfo(file); if (fileInfo.Extension.Equals(".dll")) { Assembly asm = Assembly.LoadFile(file); foreach (Type asmType in asm.GetTypes()) { if (asmType.GetInterface("MycComponent.ITaskPlugin") != null) { var plugIn = (ITaskPlugin)Activator.CreateInstance(asmType); l.Add(plugIn.TaskName, plugIn); } } } } return l; } // GetPlugins. would not compile inside an interface } /* because of the error above, I am compelled to put the helper method in a new class. a bit overkill when the method should be closely coupled to what it is implementing */ public static class ITaskPluginHelper { public static Dictionary<string, ITaskPlugin> GetPlugins(string directory) { var l = new Dictionary<string, ITaskPlugin>(); foreach (string file in Directory.GetFiles(directory)) { var fileInfo = new FileInfo(file); if (fileInfo.Extension.Equals(".dll")) { Assembly asm = Assembly.LoadFile(file); foreach (Type asmType in asm.GetTypes()) { if (asmType.GetInterface("MycComponent.ITaskPlugin") != null) { var plugIn = (ITaskPlugin)Activator.CreateInstance(asmType); l.Add(plugIn.TaskName, plugIn); } } } } return l; } // GetPlugins } // ITaskPluginHelper }
7 Réponses :
Pour votre objectif, il sera beaucoup mieux de découper l'interface de plug-in à partir de la mise en oeuvre du chargeur de plug-in: cela rendra votre conception beaucoup moins couplée et plus cohérente (ainsi que la complexité réduisant ainsi). P>
comme pour "Méthodes statiques dans l'interface", voir Ce . p>
Et comme Sidenote: vous ne voulez pas vraiment inventer une autre architecture de plug-in: jetez un coup d'œil à mef . p>
J'ai déjà inclus ce lien sur mon post ci-dessus :-) Je sais ce que vous voulez dire avec moins de conception de couplage, mais pour mon exemple ci-dessus, je pense que la mise à l'intérieur d'une interface est garantie, IMHO
Non, il n'est absolument pas justifié. Le chargement des plugins n'est absolument pas la responsabilité d'un plugin.
Je ne peux pas voir le point pourquoi il doit être absolu. Quoi qu'il en soit, je pense que plus dans C # principe de "magasin unique"
Merci pour le MEF, mais c'est toujours un développement en cours. Pour l'instant, je vais simplement rouler mon propre cadre pour les plugins, ce n'est pas cette science de la fusée
MEF est ce que le nouvel éditeur Visual Studio est intégré. Il doit être assez stable.
L'idée d'une interface est de représenter un contrat, non pas de mise en œuvre. P>
Je ne me souviens pas de désactivé si il est em> autorise des méthodes statiques avec des implémentations dans des interfaces - j'ai une suspicion sournoise qu'il fait - mais cela mène quelque peu le concept. P>
Je peux voir votre point - il est parfois utile de savoir quelles méthodes d'assistance sont disponibles qui sont connectées avec une interface (et des méthodes d'extension sont particulièrement pertinentes) mais je voudrais personnellement les mettre dans une classe distincte de toute façon, juste pour Gardez le modèle mental propre. P>
+1 pour "garder le modèle mental propre". Mais dans mon exemple, je pense que la mise en œuvre de l'assistant directement à l'intérieur d'une interface est un peu plus intuitive. et les méthodes d'extension ne vous aideront même pas ici, la méthode Helper n'a pas besoin d'un objet d'une instance Itaskplugin afin de pouvoir obtenir tous les plugins disponibles.
Ce serait utile lors de la gestion des génériques. Exemples: Dim X = T.GetDefaultValue (), Dim X = T.New (withactalarguments), etc. De nombreuses interfaces ont l'impression d'être statiques (principalement icomarables et amis).
Il n'y a pas de concept d'une "interface statique" dans le moment, mais j'ai proposé exactement cela - précisément pour les paramètres de type: msmvps.com/blogs/jon_skeet/archive/2008/08/29/... a >
Il prend explicitement les constructeurs statiques des interfaces - IL SPEC II 10.5.3
@Checoop: Les constructeurs statiques ne sont pas appelables de la même manière que les méthodes statiques sont si ... pas vraiment la même chose.
@Jon: ah, mal interprété la réponse. Il permet également des méthodes statiques et des champs sur des interfaces
Alors pourquoi ne pouvons-nous pas les définir? J'aimerais pouvoir mettre statique (ce type) désérialisze (source xmldocument); code> sur quelques-unes de mes interfaces.
Les méthodes statiques sont associées au type dans lequel elles sont déclarées et non pertinentes pour le remplacement. Si vous avez pu joindre une méthode statique à une interface, vous devez le référencer via l'interface elle-même, par ex. Ce que vous voulez faire est soit: p>
1) Placez votre méthode dans une classe de base abstraite, car les interfaces ne sont pas conçues pour contenir le code de mise en œuvre ou p>
2) Créez une méthode d'extension qui s'applique à l'interface, puis vous aurez accès à celui-ci sans avoir à utiliser une classe de base. P> Itaskplugin.getplugins (...) Code> P>
Un but de l'interface est de déclarer une interface d'un objet à travers laquelle on peut accéder. En raison du fait qu'il s'agissait de son seul but, il ne serait pas logique d'autoriser le code placé dans une interface. Si vous souhaitez toujours ajouter du code à une interface, vous pouvez utiliser des méthodes d'extension. P>
Une interface est juste que, une interface. Il n'est pas censé être utilisé pour décrire le comportement. Lorsqu'une classe implémente une interface, la classe dit simplement "Je promets que je fournisse des méthodes / événements / etc. avec ces signatures". P>
Ce que vous voulez est une interface sans la méthode statique et une classe de base abstraite qui implémente l'interface et la méthode statique. Ensuite, d'autres classes peuvent hériter de la classe de base et modifier les implémentations de la méthode de l'interface. Mais même ceci est un design discutable. P>
Je suis à plusieurs reprises et j'ai fait des recherches. La partie triste est que IL soutient en réalité cela. Je suis tellement frustré par cela j'ai écrit un article de blog à ce sujet. Vous pouvez le trouver ici . < / p>
Heureux que j'ai trouvé quelqu'un qui partage le même sentiment. BTW, je ne peux pas lire votre site Web. Blogspot est banni ici en Chine. Ma solution de contournement avant d'essayer de charger un site Web d'intérêt sur translate.google.com. Mais maintenant, même la traduction d'une page Web est bannie
Trop mauvais blogspot est banni. Il y a beaucoup d'articles très intéressants sur là. Pouvez-vous recevoir un fil d'aigreur? Si oui, vous pouvez trouver l'alimentation à mon blog ici: Feeds.FeedBurner.com/Devopopers42
+1 Pour relier mon blog dans le message que vous liez à ;-), le blog est mort, mais j'ai posté le code ci-dessus.
Vous pouvez mettre à jour votre blog avec les nouvelles fonctionnalités de C # 8. Il permet aux membres statiques des interfaces: docs.microsoft.com/en-us/dotnet/cshaarp/Torytials/...
Consultez mon entrée de blog sur des méthodes statiques implémentées dans des interfaces (désolé pour la référence d'auto sans vergogne)
[Suppression de la liaison brisée HTTP: / ...] p>
Le site DotNetJunkies est pisé par TotalDevPRO. .. donc la version de Google mis en cache est la seule disponible sur p>
éditer: J'ai collé une version mise en cache ci-dessous, j'ai trouvé: p>
[...] p>
Utilisez ilasm pour compiler les éléments suivants: P>
System.Type myInterface = typeof(MaLio.IMyInterface); // show that we really are dealing with an interface if (myInterface.IsInterface) { System.Reflection.MethodInfo staticMethod = myInterface.GetMethod("DoStaticWork"); staticMethod.Invoke(null, null); }
-1 Le lien est mort, IP référencé au lieu d'un nom de domaine, mis en cache ne semble rien montrer maintenant
Fixé ... collé dans l'entrée
duplicatural possible de Pourquoi nous pouvons ne pas avoir de fonctions / méthodes statiques (statiques) partagées dans une classe d'interface / abstraite?
Il pense que vous pourrez le faire en C # 8!
Voir: Docs.Microsoft.com/fr- US / DotNet / Csharp / Tutoriels / ...