2010-10-01 4 views
0

Dans une classe partiellement modifiable, est-il préférable de mélanger des champs mutables avec des champs mutables, ou créer une nouvelle classe (ou classes) qui les encapsule? Voici un exemple en C# de ce dont je parle:Mutabilité de classes mixtes et séparées

interface IBedroom 
{ 
    int Volume { get; } 

    string Color { get; } 

    void Paint(string newColor); 
} 

Voici une implémentation avec mutabilité mixte dans ses domaines:

class MixedMutabilityBedroom : IBedroom 
{ 
    readonly int volume; 
    string color; 

    public MixedMutabilityBedroom(int volume, string color = "") 
    { 
     this.volume = volume; 
     this.color = color; 
    } 

    public int Volume 
    { 
     get { return volume; } 
    } 

    public string Color 
    { 
     get { return color; } 
    } 

    public void Paint(string newColor) 
    { 
     color = newColor; 
    } 
} 

et un avec mutabilité séparé:

// first, a fully mutable helper class 
class RoomColor 
{ 
    string value; 

    public RoomColor(string value) 
    { 
     this.value = value; 
    } 

    public string Value 
    { 
     get { return value; } 
    } 

    public void Change(string newValue) 
    { 
     value = newValue; 
    } 
} 

et l'implémentation de mutabilité séparée:

class SeparatedMutabilityBedroom : IBedroom 
{ 
    readonly int volume; 
    readonly RoomColor color; 

    public SeparatedMutabilityBedroom(int volume, RoomColor color) 
    { 
     this.volume = volume; 
     this.color = color; 
    } 

    public int Volume 
    { 
     get { return volume; } 
    } 

    public string Color 
    { 
     get { return color.Value; } 
    } 

    public void Paint(string newColor) 
    { 
     color.Change(newColor); 
    } 
} 

Personnellement, je suis du côté de ce dernier style. Dans mon expérience, les bogues qui découlent de la manipulation d'état dans des scénarios simultanés sont difficiles à déboguer. Comme la concurrence devient la norme pour les programmes, il semble que la mutabilité localisée soit un facteur clé pour réduire les efforts de débogage. Dans le second exemple, nous n'avons pas besoin de regarder par-dessus l'implémentation de la classe entière pour savoir où l'état est manipulé. La totalité de la mutabilité de SeparatedMutabilityBedroom est localisée à RoomColor.

Qu'en pensez-vous? Ai-je oublié quelques points à considérer?

+0

Pourquoi diable marqueriez-vous quelque chose d'immuable et le changeriez-vous? Indépendamment de «voir où la mutabilité peut être», certainement aucune des choses que vous avez l'intention de changer ne devrait être marquée comme immuable, ni aucune des choses qui encapsulent ces choses. Parlez des bogues qui attendent de se produire et qui ne communiquent pas l'intention! "Hé cette chose a dit que c'était immuable et puis ça a changé sur moi." WTF? " –

+0

@ dash-tom-bang, pourriez-vous clarifier s'il vous plaît? Qu'ai-je marqué comme immuable et ensuite changé? –

+0

RoomColor est marqué comme étant en lecture seule, mais la méthode Paint le modifie. –

Répondre

0

La programmation avec des structures de données immuables est une technique très utile, mais il est difficile de critiquer une meilleure pratique générale ou une suggestion basée sur un exemple simple. Décider ce qui est le mieux doit prendre en compte d'autres facteurs tels que la façon dont cette classe est utilisée et interagit avec. Cependant, en supposant que vous êtes dans une situation où il y a une grande quantité de simultanéité avec plusieurs auteurs sur cet objet, alors rendre un objet partiellement immuable ne vous achètera pas beaucoup puisque vous pouvez toujours rencontrer des problèmes.

Dans ce cas, utilisez une sorte de primitive de synchronisation ou utilisez un objet complètement immuable.

Cette answer parle de certaines techniques d'utilisation d'objets complètement immuables.

Questions connexes