Dans l’attente de lire le prochain post sicharpien !

Quant aux méthodes de SwitchExtensions, elles permettent ici de gérer le cas où @this est null, justement. Les appels à la méthode Case sont voués à être chainés, or cette dernière retourne null lorsqu’une correspondance est trouvée pour sortir du switch.

Ayant appris à utiliser yield grâce à un post précédent, j’accorde le plus grand intérêt aux solutions proposées par Romain. :-)

Toutefois, 2 choses m’échappent dans cette suggestion :

1°) L’arobase qui préfixe le nom du paramètre @this a-t-il une signification particulière dans le langage, ou bien est-ce simplement un caractère légal comme un autre pour nommer un paramètre, et c’est juste que je l’ignorais ?

2°) Pourquoi avoir créé une seconde classe SwitchExtensions pour étendre la classe Switch plutôt que de pourvoir directement celle-ci des méthodes Case et Default (et travailler directement avec le “vrai” this) ?

Merci d’avance pour les éclaircissements ! :-)

 if (this.GetType().GetProperties().Count() > 0)
                foreach (PropertyInfo p in this.GetType().GetProperties())
                {
                    Object result = p.GetValue(this, null);

                    if (result == null)
                    {
                        p.SetValue(this, createNodeInstance(Assembly.GetAssembly(p.PropertyType), p.PropertyType.FullName), null);
                        switch (Assembly.GetAssembly(p.PropertyType).GetName().Name)
                        {
                            case "ModelObject":
                                Object newObject = createNodeInstance(Assembly.GetAssembly(p.PropertyType), p.PropertyType.FullName);
                                p.SetValue(this, newObject, null);

                            default: break;
                        }
                    }
                }

Mais je pense qu’en restant dans un contexte de swicth/case, l’argument de la lisibilité est valable. On parle d’une logique “basique”, contrairement à l’exemple de la méthode “IsPrime”.

De la même manière pour un swicth/case un nombre limité de cas, et avec des opérations relativement simple, le “if-is-cast” sera plus facile à comprendre.

Cependant, avec la même construction mais un nombre plus conséquent de cas, et des opération plus complexe pour chacun des cas, ta solution prouve toute son utilité.

Pour moi ça reste une question de contexte dans le code.

Ceci-dit , quit à imaginer des méthodes élegantes, j’aurai je pense tenté de me débarasser du switch et suivre le conseil avisé : “la première chose qu’il vous faut faire est de vous demander si vous avez besoin de faire un switch sur un type[...]“. (on m’objectera qu’en matiere d’”over design”, contourner un switch aboutit parfois a bien pire que la solution présentée :s)

Ce ceci-dit dit, j’avoue que je ne me serais jamais posé la question de savoir comment j’allais éviter un switch (ou assimilé if..elseif, etc.) par “mon propre switch”, c’est vraiement une belle solution.