如何设计解决 C#/Java 中缺少 const 的问题？

Question

在尝试对我的域进行建模时，我遇到了以下问题。让我们想象一下，我们有一个东西：

class Thing
{
    public int X { get; set; }
}

东西有一个属性 X。然后，有一些包，它聚合了东西。但领域要求对包可以容纳的东西有一些限制。举例来说，Xes 的累积值不能高于某个特定限制：

class Pack
{
    private readonly List<Thing> myThings = new List<Thing>();
    private const int MaxValue = 5;

    public void Add(Thing thing)
    {
        if (myThings.Sum(t => t.X) + thing.X > MaxValue)
            throw new Exception("this thing doesn't fit here");
        myThings.Add(thing);
    }

    public int Count
    {
        get { return myThings.Count; }
    }

    public Thing this[int index]
    {
        get { return myThings[index]; }
    }
}

因此，我在将事物添加到包之前检查条件，但仍然很容易陷入麻烦：

var pack = new Pack();
pack.Add(new Thing { X = 2 });
pack.Add(new Thing { X = 1 });

var thingOne = new Thing { X = 1 };
var thingTwo = new Thing { X = 3 };

//pack.Add(thingTwo); // exception
pack.Add(thingOne);   // OK

thingOne.X = 5;       // trouble
pack[0].X = 10;       // more trouble

在 C++ 中，解决方案将是在插入时制作副本并在索引器中返回 const 引用。如何在 C#（也可能是 Java）中围绕这个问题进行设计？我似乎想不出一个好的解决方案：

1. 使 Thing 不可变 - 但如果它需要可变怎么办？
2. 使用 event/observer 观察 Pack 中的事物 - 但这意味着 Pack 强加了 Thing 的设计；如果事物有更多属性怎么办？然后，由于需要 Pack 来观察变化，我最终将只进行一项活动 - 这对我来说似乎很尴尬。

有什么想法或首选解决方案吗？

编辑：

回到这个问题...我已经接受了 Itay 的回复。他是对的。 最初的问题是，在一个上下文中，您希望 Thing 对象是不可变的，而在不同的上下文中，您会希望它是可变的。这需要一个单独的界面......也许吧。我说“也许”，因为大多数时候，Pack 是事物的聚合（在 DDD 意义上），因此是对象的所有者 - 这意味着它不应该让您能够更改所拥有的对象（或者返回一个副本或返回一个不可变的接口）。

很高兴在 C++ 中这个特殊的事情可以通过 const 修饰符如此轻松地处理。如果你想让事情保持一致的状态，那么编码似乎要少得多。

Answer 1

使 Thing 不可变。

class Thing
{
    public Thing (int x)
    {
       X = x;
    }
    public int X { get; private set; }
}

另外，我认为最好在 pack 中保存一个 sum 字段，而不是 if (myThings.Sum(t => tX) + thing.X > MaxValue) ，这样你就不用每次重新计算总和。

编辑
抱歉 - 我错过了您说过您需要它可变的事实。
但是...你的 C++ 解决方案如何工作？我不太了解 C++，但 C++ 常量引用不会阻止包上实例的更改吗？

编辑2
使用接口

public interface IThing
{
  int X { get; }
}

public class Thing : IThing
{
  int X { get; set; }
}

class Pack
{
    private readonly List<IThing> myThings = new List<IThing>();
    private const int MaxValue = 5;

    public void Add(IThing thing)
    {
        if (myThings.Sum(t => t.X) + thing.X > MaxValue)
            throw new Exception("this thing doesn't fit here");
        myThings.Add(new InnerThing(thing));
    }

    public int Count
    {
        get { return myThings.Count; }
    }

    public IThing this[int index]
    {
        get { return myThings[index]; }
    }

    private class InnerThing : IThing
    {
      public InnerThing(IThing thing)
      {
        X = thing.X;
      }
      int X { get; private set; }
    }
}

Answer 2

您可以让 Thing 实现 iReadOnlyThing 接口，该接口仅对 Thing 的每个属性具有只读访问权限。

这意味着将大部分属性实现两次，也意味着相信其他编码人员尊重 iReadOnlyThing 接口的使用，而不是偷偷地将任何 iReadOnlyThings 转换回 Things。

相同的方式实现只读容器类

System.Collections.ObjectModel.ObservableCollection<T>

您可能会以与和

System.Collections.ObjectModel.ReadOnlyObservableCollection<T>

。 ReadOnlyObservableCollection 的构造函数采用 ObservableCollection 作为其参数，并允许对集合进行读访问，但不允许写访问。它的优点是不允许将 ReadOnlyObservableCollection 强制转换回 ObservableCollection。

我觉得我应该指出，WPF 开发中使用的模型-视图-视图模型模式实际上确实按照您建议的原则工作，即拥有一个 NotifyPropertyChanged 事件，其中包含一个标识已更改属性的字符串

... MVVM 模式的编码开销很大，但有些人似乎喜欢它......

Answer 3

按照您的陈述，您确实在 X 背后有一些业务逻辑，在设置 X 时也必须应用这些业务逻辑。如果要触发某些业务逻辑，您应该仔细考虑如何设计 X。它不仅仅是一种财产。

您可以考虑以下解决方案：

• 您真的需要允许更改 X 吗？即使该类不是不可变的，您仍然可以将 X 设置为只读。
• 提供一个 SetX(...) 方法，该方法封装了业务逻辑，以检查 Thing 是否是 Pack 的一部分并调用该 >Pack 的验证逻辑。
• 当然，您也可以使用属性 set { } 来代替 setter 方法来实现该逻辑。
• 在 Pack.Add 中，创建 Thing 的副本，它实际上是添加验证逻辑的子类。
• ...

无论你做什么，你都无法回避以下非常基本的设计问题：要么你允许改变X，那么你必须在允许改变X的每个部分中引入验证/业务逻辑。或者你让X只读并调整应用程序中可能想要相应更改 X 的部分（例如删除旧对象、添加新对象...）。

Answer 4

对于简单的对象，您可以使它们不可变。但不要过度。如果您使复杂对象不可变，您可能需要创建一些构建器类才能使用它。这通常是不值得的。

并且您不应该创建具有不可变身份的对象。通常，如果您希望对象表现得像值类型，则可以将其设置为不可变。

在我的一个项目中，我通过只为基类提供 getter 并将 setter 隐藏在派生类中来实现不变性。然后为了使对象不可变，我将其强制转换为基类。当然，这种类型的不变性不是由运行时强制执行的，并且如果您需要类层次结构用于其他目的，则这种不变性不起作用。

Answer 5

在 Thing 中添加 Change 事件怎么样？ Pack 订阅此事件，当您更改 Thing 中的 X 时，Pack 会在事件处理程序中进行必要的检查，如果更改不适合；抛出异常？

Answer 6

不幸的是，C# 中没有任何东西比 C/C++ 中的 const 更强大，可以确保（在编译时）值不会被更改。

它们唯一的特点就是不变性（就像你自己和 Itay 提到的那样），但它没有像 const 那样的灵活性。 :(

如果您在某些情况下需要它可变，您只能在运行时执行类似这样的操作

class Thing
{
    public bool IsReadOnly {get; set;}

    private int _X;
    public int X
    {
        get
        {
            return _X;
        }
        set
        {
            if(IsReadOnly)
            {
                throw new ArgumentException("X");
            }

            _X = value;
        }
    }
}

，但它会用 try/catch 污染您的代码并更改 IsReadOnly 的值。所以不是很优雅，但也许值得考虑。

Answer 7

我会考虑重新设计您使用该包的方式。

如果您从集合中删除要修改的事物，并且不仅仅允许直接访问，则在将其放回时将会对其进行检查。

当然，缺点是您必须记住将其放回包装中！

或者在 Pack 上提供方法来修改事物，以便您可以检查正在设置的值是否违反域规则。