2009-11-08 10 views
2

Je tente de créer une bibliothèque BitTorrent en C# en tant que projet parallèle, pour le plaisir. Cependant, j'ai rencontré un problème de conception qui pourrait créer des problèmes plus tard si je ne l'aborde pas maintenant.Créer une nouvelle instance d'un objet, ou modifier celui existant?

J'ai actuellement une classe PeerGreeter, qui met un Socket dans un état d'écoute pour tous les pairs qui essayent de se connecter, pour me servir des fichiers dans le torrent. Lorsqu'un homologue se connecte, le greeter échange des poignées de main, s'assure que tout est valide, puis déclenche un événement PeerConnected avec les informations associées Socket et handshake en tant qu'arguments de gestionnaire.

Ma classe Torrent, qui est une représentation d'un seul torrent et de toutes ses fonctions, possède deux listes de tous les pairs de l'essaim (encapsulés dans un objet Peer), connectés et déconnectés. Lorsque le greeter déclenche l'événement PeerConnected, l'instance Torrent trouve le Peer correspondant dans la liste déconnectée. S'il en trouve un, il le place dans la liste connectée et définit une propriété Connection de type Socket dans son instance au Socket créé par le greeter. La propriété est une auto-propriété avec les modificateurs d'accès comme: { get; internal set; }

Le problème que je rencontre est que, pour autant que je sache, ce n'est pas thread-safe. Si un thread travaille avec une connexion d'un Peer, puis qu'un autre thread modifie cet objet de connexion ou le supprime, cela peut créer des problèmes. J'ai envisagé de définir le modificateur d'accès de la propriété Connection à private, et de le définir dans le constructeur, mais le problème est que je dois créer un nouvel objet pour remplacer l'espace réservé Peer dans la liste déconnectée pour l'ajouter au liste connectée.

Ma question est-ce que je devrais rester avec le setter comme internal, ou le fait private et en remplaçant l'espace réservé avec une instance entièrement nouvelle une bonne approche aussi bien?

Répondre

2

Pour des raisons de sécurité des threads, rendre le type aussi immuable que possible vous évitera de nombreux maux de tête. Rendre l'accesseur privé (ou mieux encore, marquer le champ readonly) et générer de nouvelles instances lorsque des modifications doivent être apportées.

Questions connexes