Est-ce que ce code est redondant?

Question

Je suis la mise à niveau d'un système et je passe par un autre code de développeurs (ASP.NET en C#).

je suis tombé sur ceci:

private ReferralSearchFilterResults ReferralsMatched 
{ 
    get 
    { 
     if (Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] == null || Session[SESSION_REFERRAL_SEARCHFILTERRESULTS].GetType() != typeof(ReferralSearchFilterResults)) 
      return null; 
     else 
      return (ReferralSearchFilterResults)Session[SESSION_REFERRAL_SEARCHFILTERRESULTS]; 
    } 
    set 
    { 
     if (value == null) 
     { 
      Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] = value; 
     } 
     else if (value.GetType() == typeof(ReferralSearchFilterResults)) 
     { 
      Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] = value; 
     } 
    } 

} 

vérifie le type du setter inutile? Sûrement, si je définissais la propriété à autre chose qu'un objet ReferralSearchFilterResults, le code ne serait même pas compiler? Est-ce que je manque quelque chose ou suis-je raison de penser cela peut être réalisé en utilisant simplement:

set 
{ 
    Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] = value; 
} 

Answer 1

Le code d'origine empêche toute sous-classes de ReferralSearchFilterResults d'être ou de fixer ou de la propriété. C'est parce que value.GetType() va retourner le Type réel de l'objet référencé par value. Si ce Type est une sous-classe de ReferralSearchFilterResults, il ne sera pas égal à typeof(ReferralSearchFilterResults).

Je ne suis pas sûr de votre contexte ici, donc je ne peux pas vous dire si c'est un comportement correct ou non. Si c'est le comportement prévu, il sent un peu sale car il ignorera silencieusement toutes les affectations de sous-classes. Mais je ne peux pas vraiment juger sans plus de contexte.

Answer 2

Je pense que vous avez raison - le poseur ne doit pas compiler si elle est fournie avec quelque chose de qui ne peut pas être implicitement à une ReferralSearchFilterResults.

Answer 3

Je peux comprendre le type de vérification dans le bit get, mais comme vous le dites, dans le setter, vous ne pouvez pas passer dans tout ce qui n'est pas un ReferralSearchFilterResults, car le code échouerait au moment de la compilation.

(Peut-être une vieille habitude, l'autre développeur a)

Answer 4

Pour la partie get, vous pouvez utiliser

return Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] as ReferralSearchFilterResults; 

Cela renvoie la valeur si elle peut être casté en ReferralSearchFilterResults, sinon null.

Answer 5

Jamie vous avez raison. La vérification de type sur le Setter n'est pas nécessaire dans ce cas car valuedoit être un ReferralSearchFilterResults.

Un autre changement que vous pourriez envisager est d'utiliser les mots-clés is et as au lieu de comparer Type objets.

private ReferralSearchFilterResults ReferralsMatched 
{ 
    get 
    { 
     if (Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] == null || !(Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] is ReferralSearchFilterResults)) 
      return null; 
     else 
      return Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] as ReferralSearchFilterResults; 
    } 
    set 
    { 
     Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] = value; 
    } 

} 

Answer 6

variables de session sont l'objet de type, de sorte que vous pouvez stocker quoi que ce soit à l'intérieur de ceux-ci. Mais dans ce cas, le setter lui-même empêche le programmeur d'affecter un autre type d'objet que ReferralSearchFilterResults et les objets dérivés. Donc le chèque, comme vous l'avez souligné, n'est pas nécessaire. De plus, il ne permet pas à un programmeur d'assigner un objet dérivé de ReferralSearchFilterResults. Mais j'utiliserais Session.Remove plutôt que de simplement définir la variable sur null, car la variable de session existerait toujours dans le contexte http si elle était définie sur null uniquement.

Alors:

set 
{ 
     if (value == null) 
      Session.Remove(SESSION_REFERRAL_SEARCHFILTERRESULTS); 
     else 
      Session[SESSION_REFERRAL_SEARCHFILTERRESULTS] = value; 
}