最近我一直在实现的利益（有些人认为过度使用）不可变对象大幅减少在我的对象模型读写依赖问题及其产生的条件和副作用，最终使code易于管理（一种功能性编程去年秋季的）。

Lately I've been realizing the benefit of (some would argue overuse of) immutable objects to cut down dramatically on read-write dependency issues in my object model and their resulting conditions and side-effects, to ultimately make the code simpler to manage (kind of functional-programming-esque).

这种做法使我产生在创建/施工时提供值只读对象，然后使仅公开干将外部呼叫者可以访问属性。受保护的，内部和私人制定者允许维持在写对象模型的内部控制。

This practice has led me to create read-only objects that are provided values at creation/construction time and then to make available only public getters for external callers to access the properties with. Protected, internal and private setters allow internal control to be maintained over writing to the object model.

在创建接口，同时使一个API，在我的对象模型，我已经开始考虑有关不变性同样的问题。例如，通过提供对我的接口仅公共干将，并留下它来实现者作出决定制定者以及如何处理这一方面。

When creating interfaces while making an API over my object model, I've started considering the same issues about immutability. For example, by providing only public getters on my interfaces, and leaving it up to implementors to decide upon setters and how to handle that aspect.

一个只读的接口实现，我谈论的一个例子是这样的贵重物品（只是为了演示）：

An example of a "read-only" interface for implementation that I'm talking about is this Valuable Item (just for demonstration):

public interface IValuableItem {
    decimal Amount {get;}
    string Currency {get;}
}

不过，我得想知道的我应该如何提供一个辅助接口，允许写入（如果我要），而不是在同一界面中结合这些操作，以不污点的不变性

However I got to wondering how I should provide a companion interface that allows for writing (and if I should), and not combine those operations within the same interface as to not "taint" its immutability.

下面的想法浮现在脑海中，就在我的头顶。如果没有提供什么，我认为是优点和缺点每个，你觉得最好的办法是？有没有在同行业中常见的编码方法来管理这个概念？

The following ideas have come to mind, just off the top of my head. Without providing what I think are pros and cons to each, what do you think the best approach is? Is there a coding methodology common in the industry for managing this concept?

// companion writer
public interface IValuableModifier {
    decimal Amount {set;}
    string Currency {set;}
}

或

// explicit methods to enforce importance of or deviance in the programming
public interface IValuableModifier {
    void SetAmount(decimal val);
    void SetCurrency(string cur);
}

或

// companion writer that inherits the original interface
public interface IValuableModifier : IValuableItem { //...

或

// Let a concrete class choose one and/or the other.
class Concrete  : IValuableModifer, IValuableItem { //...

或

等... 还有什么可以帮我灌输写在我的否则是不可改变的编程模型，并保持适度的灵活性，或者至少单独进行更好的控制的担忧呢？

etc... What else can help me imbue writing on my otherwise immutable programming model and keep it moderately flexible or at least to separate the concerns for better control over it?

推荐答案

我想我可能会使用你的想法变体，是这样的：

I think I might use a variant of your ideas, something like this:

public interface IValuableItem
{
    decimal Amount { get; }
    string Currency { get; }
}

public interface IMutableValuable : IValuableItem
{
    new decimal Amount { set; get; }
    new string Currency { set; get; }
}

class Item : IMutableValuable
{
    public decimal Amount { get; set; }
    public string Currency { get; set; }
}

这样，你的可变接口具有完全getter和setter方法​​（我不认为这是有道理的有一个具有制定者，但没有getter方法​​的接口），但实现它的任何对象也将有接口的不可变版本你可以使用任何纯功能code。

This way your mutable interface has full getters and setters (I don't think it makes sense to have an interface that has setters but no getters), but any object that implements it will also have an immutable version of the interface that you can use for any pure-functional code.