Question

Après avoir lu de nombreuses réponses à Sur ce fil , je constate que beaucoup de ceux qui ne le supportent pas citent le potentiel d’utilisation abusive du nouveau mot clé. Ma question est, quel genre d'abus? Comment cela pourrait-il être si mal utilisé que les gens le détestent avec véhémence? Est-ce juste du purisme? Ou y a-t-il un vrai piège que je ne vois pas?

Était-ce utile?

La solution

Certains y voient un outil qui fera l’objet d’abus. J'aime & Option; Strict Off " et " On Error Resume Next " en VB qui "pur" des langages comme C # et Java n’ont jamais existé.

Beaucoup ont dit la même chose à propos du "var". mot-clé, mais je ne le vois pas maltraité, une fois que l'on a compris que ce n'était pas la même chose que le "Variant" de VB

On pourrait en abuser à des endroits où les développeurs paresseux ne veulent pas vérifier les classes et essaient simplement d’attraper les appels dynamiques au lieu d’écrire "si blah est Blah ...".

Personnellement, j’ai le sentiment que cet appareil pourrait être utilisé correctement dans des situations comme this recent question à laquelle j'ai répondu.

Je pense que ceux qui comprennent vraiment son pouvoir sont ceux qui entrent dans les langages dynamiques .NET.

Autres conseils

Je pense qu’une grande partie de la répulsion exprimée par les utilisateurs de cette fonctionnalité se résume à: "c’est une fonctionnalité très mauvaise en termes de langage, car elle permet aux mauvais développeurs d’écrire du mauvais code". Si vous y réfléchissez, toutes les fonctionnalités du langage sont mauvaises.

Lorsque je rencontre un bloc de code VB qu'un génie a préfixé par On Error Resume Next , ce n'est pas VB que je maudis. Peut-être que je devrais, je suppose. Mais selon mon expérience, une personne qui est déterminée à mettre un sou dans la boîte à fusibles va trouver un moyen. Même si vous videz ses poches, il fabriquera ses propres sous.

Moi, je suis impatient de trouver un moyen plus utile d'interagir entre C # et Python. J'écris de plus en plus de code qui fait cela. Le mot clé dynamic ne peut pas arriver assez tôt pour ce cas d'utilisation particulier, car la manière actuelle de le faire me donne l'impression que je suis un universitaire soviétique des années 1950 qui se rend en Occident pour une conférence. : il y a énormément de règles et de formalités à remplir avant de partir, je suis presque certain que quelqu'un me surveillera tout le temps que je serai là-bas, et la plupart de ce que je capte pendant que je suis là sera enlevé moi à la frontière quand je reviens.

dynamique est incorrect, car un code comme celui-ci apparaîtra partout:

public dynamic Foo(dynamic other) {
  dynamic clone = other.Clone();
  clone.AssignData(this.Data);
  return clone ;
}

au lieu de:

public T Foo<T>(T other) where T: ICloneable, IAssignData{
    T clone = (T)other.Clone();
    clone.AssignData(this.Data);
    return clone;
}

Le premier ne contient aucune information de type statique, aucune vérification de temps de compilation, il n'est pas auto-documenté, aucune inférence de type, de sorte que les utilisateurs sont obligés d'utiliser une référence dynamique sur le site de l'appel pour stocker le résultat, ce qui entraîne davantage de pertes de type. et tout cela en spirale.

Je commence déjà à craindre la dynamique .

Modifier : le danger est passé (Ouf!) ... et la dynamique n'a pas été abusée après tout, inutile de me voter après 3 ans:)

Le véritable piège? Manque grave de documentation. Toute l'architecture de l'application existe dans l'esprit de la personne (ou des personnes) qui l'a écrite. Au moins avec le typage fort, vous pouvez aller voir ce que fait l'objet via sa définition de classe. Avec le typage dynamique, vous devez au mieux déduire le sens de son utilisation. Au pire, vous n'avez aucune idée de ce qu'est l'objet. C'est comme tout programmer en JavaScript. ACK!

Lorsque les utilisateurs s'aperçoivent qu'ils n'obtiennent pas le bon IntelliSense avec dynamic , ils cessent d'être dynamiques -happy en dynamiques . -when-required-and- var à tous les autres moments.

Les objectifs de dynamic sont les suivants: interopérabilité avec les langages dynamiques et les plates-formes telles que COM / C ++ et DLR / IronPython / IronRuby; en plus de transformer C # lui-même en IronSmalltalkWithBraces avec tout ce qui met en œuvre IDynamicObject .

Tous auront de bons moments. (Sauf si vous devez gérer le code écrit par quelqu'un d'autre.)

C’est un peu comme discuter de caméras publiques, bien sûr, elles peuvent et seront mal utilisées, mais il ya aussi des avantages à les avoir.

Il n'y a aucune raison pour que vous ne puissiez pas interdire les "dynamiques". mot-clé dans votre propre directive de codage si vous n'en avez pas besoin. Donc quel est le problème? Je veux dire, si vous voulez faire des choses folles avec le "dynamique" mot-clé et prétendez que C # est le cousin mutant de JavaScript, soyez mon invité. Gardez ces expériences hors de ma base de code. ;)

FUD. C'est peut-être la meilleure chose depuis le pain en tranches, mais toute l'expérience que j'ai avec VB, JavaScript, etc., me donne les frissons de savoir que C # aura une liaison dynamique. Je sais que je pourrai l'examiner de manière rationnelle dans un proche avenir et voir à quel point cette nouvelle fonctionnalité sera utile pour permettre l'interopérabilité avec des langages dynamiques. Mais cela prendra du temps. Je suis humain, d'accord? : -)

Je ne vois pas pourquoi le mode actuel d'invocation dynamique de méthodes est défectueux:

Il faut trois lignes pour le faire ou vous pouvez ajouter une méthode d'extension sur System.Object pour le faire à votre place:

class Program
{
    static void Main(string[] args)
    {
        var foo = new Foo();            
        Console.WriteLine(foo.Invoke("Hello","Jonathan"));
    }        
}

static class DynamicDispatchHelper
{
    static public object Invoke(this object ot, string methodName, params object[] args)
    {
        var t = ot.GetType();
        var m = t.GetMethod(methodName);
        return m.Invoke(ot, args);
    }
}

class Foo
{
    public string Hello(string name)
    {
        return ("Hello World, " + name);
    }
}
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top