Méthode de masquage avec des interfaces

Question

interface IFoo 
{ 
    int MyReadOnlyVar { get; } 
} 


class Foo : IFoo 
{ 
    int MyReadOnlyVar { get; set; } 
} 


public IFoo GetFoo() 
{ 
    return new Foo { MyReadOnlyVar = 1 }; 
} 

Est-ce que ce qui précède est un moyen acceptable de mettre en œuvre un objet en lecture seule/immuable? L'immutabilité de IFoo peut être rompue avec une distribution temporaire à Foo.

Dans les cas généraux (non critiques), est-ce que la fonctionnalité de dissimulation via les interfaces est un modèle commun? Ou est-ce considéré comme un codage paresseux? Ou même un anti-pattern?

Answer 1

L'utilisation d'interfaces pour masquer rend l'utilisation d'une classe plus petite. J'ai vu beaucoup de ce type de code dans les applications Spring où les dépendances sont seulement exprimées dans la classe (et utilisées par l'injection de dépendance Spring) et non dans l'interface car elles ne fournissent rien pour le domaine.

Vous ne pouvez pas protéger votre code contre d'autres codeurs. Si vous avez peur que quelqu'un jette l'interface vers la version mutable, la même chose pourrait se produire si vous renvoyez un instantané réel en lecture seule et qu'un membre de votre équipe ajoute des méthodes de mutation.

Cela dépend aussi de votre code. Dans un projet/une application, vous pouvez faire confiance à vos collègues. Lors de l'élaboration d'un cadre, les choses sont différentes. Ensuite, vous devez décider si vous souhaitez toujours renvoyer des objets "enregistrer", par ex. clones de listes au lieu des listes réelles qui pourraient être modifiées. Donc oui, en général (non critique) cas à mon humble avis, il est approprié de le faire à votre façon.

Answer 2

Vous pouvez rendre la classe Foo visible au niveau de l'assemblage uniquement (interne en C#), ou rendre le setter de MyReadonlyVar interne, afin que votre code soit protégé des lancers inutiles en dehors de l'assemblage.