J'ai hérité d'une base de code de DLL C# qui sont appelées via COM-interop (ou ainsi il a été décrit). Le code C# utilise également des objets COM en interne pour exécuter la fonctionnalité de base de l'application parente.Objet COM dans la classe de base - accès via un champ ou une propriété?
Je suis en train de refactoriser certaines des violations DRY du code car trouver des duplications dans 100 000 lignes de code sur 50 ou 60 DLL est inefficace. Je suis tombé sur une utilisation d'objets COM dans des classes de base abstraites que je voudrais normaliser un peu, mais je n'ai trouvé aucune affirmation clairement définitive sur cette utilisation particulière des objets COM en C#.
Notre code a actuellement plusieurs classes de base qui contiennent des objets COM, codés comme ceci:
public abstract class SomeBaseClass()
{
protected IComObject comObject;
protected virtual void Initialize(IComObject comObject)
{
this.comObject = comObject;
}
protected SomeBaseClass() { }
}
Pour éviter this.comObject d'être situé dans un autre que initialize(), je voudrais mettre en œuvre ces de base À mon avis, le deuxième exemple me semble meilleur et me donne plus de contrôle sur le comObject interne. Actuellement, les classes dérivées existantes (C#) ne définissent pas directement la classe de base comObject, mais utilisent Initialize(), mais rien ne les empêche d'affecter directement à la classe de base comObject. Je veux empêcher la future erreur potentielle d'assigner à comObject en dehors de Initialize().
Y a-t-il une raison pour laquelle la deuxième implémentation de la classe de base de la gestion des objets COM ne fonctionnera pas? Dans mes tests limités, ça semble fonctionner, mais vous êtes plus malin que moi.
merci!
Je ne connais pas ce scénario COM 100% (donc pas une réponse), mais en règle générale, les champs doivent être privés * jusqu'à ce que * il y ait une bonne raison de ne pas l'être. Donc, je vote l'option 2. –
@ Marc: Merci, cela reflète aussi ma pensée. J'espère juste éviter les pièges. v) – james