我有点晚了，但我没有看到一个答案，建议根本不做!让它保持不变。当他们把你的方法放入循环时，你所使用的任何方法都会被滥用，这最终会发生。相反，我建议使用建造器。

MyImmutableBuilder builder = new MyImmutableBuilder(someImmutable);
MyImmutable modifiedImmultable = builder.add(element1).add(element2).build();

在ImmutableList的情况下，你的构建器很可能只是一个List。

I guess it all boils down to... to you really want an easy way to add just a single element to your immutable collection? If it's a common occurrence, you probably don't want to be using an immutable object (you can always call build() any time you want to send a snapshot of the object at it's present state...) If it's not a common occurrence, then having a builder as a requirement to do it wouldn't be a significant impediment, especially if it were documented that this is how you want to build them.

@supercat -考虑你描述的以下场景:

Stack a = someImmutableStackOfSize(10);
Stack b = a.popAndCopy(); // size 9
Stack c = a.popAndCopy(); // also size 9
// a b and c have the same backing list
Stack d = b.pushAndCopy("node1");
Stack e = c.pushAndCopy("node2");
// because d and e had the same backing list, how will it 
// know that d's last element is node1, but e's last
// element is node2?

我知道这似乎是在徒劳无益，但我认为您可能会以一种奇怪的方式来处理这个问题(因此命名困难)。当我有一个不可变的对象时，我通常不期望该对象具有暗示可变性的函数(如Add或AddAll)。我知道字符串和DateTime这样做，但即使我已经成为受害者，忘记使用DateTime / String函数的结果，所以我会尽可能避免这些陷阱。

如果我是您，我会遵循类似于Guava使用的Builder模式。参见Guava中的不可变集合。基本上，这个概念是用它所包含的所有内容来构造不可变对象。如果你想要创建一个新的不可变对象，你需要使用一个新的构建器。

var suite = new TestSuite.Builder<string, int>().add(newTest).build();

在用户调用构建之前，您可以扩展构建器以允许对测试套件进行各种修改(如果您愿意，可以使用标准列表命名约定，如添加/删除)。

虽然正确命名方法可以减少误用的机会，但如果有一些语言构造告诉编译器:“这个方法什么都不做，只是返回一个新对象，它应该被使用，否则方法调用是没有意义的”，那么每当有人在错误的设置中使用该方法时，编译器就会报错/警告。

我已经为此填写了一个功能请求，如果你同意，可以自由投票。

对于这种功能，我通常使用动词的第二种形式，在这种情况下是Added。

这个约定被Qt使用，例如QVector2D::normalized返回一个归一化的向量，而QVector2D::normalize则归一化一个向量。

以同样的方式，Added将返回带有新添加项的对象。

也许混淆源于您想要两个操作合一的事实。为什么不把它们分开呢?DSL风格:

var list = new ImmutableList<string>("Hello");
var list2 = list.Copy().With("World!");

Copy会返回一个中间对象，这是原始列表的可变副本。With将返回一个新的不可变列表。

更新:

但是，使用中间的、可变的集合并不是一个好方法。中间对象应该包含在Copy操作中:

var list1 = new ImmutableList<string>("Hello");
var list2 = list1.Copy(list => list.Add("World!"));

现在，Copy操作接受一个委托，该委托接收一个可变列表，因此它可以控制复制结果。它能做的远不止追加一个元素，比如删除元素或对列表排序。它还可以在ImmutableList构造函数中使用，在没有中间不可变列表的情况下组装初始列表。

public ImmutableList<T> Copy(Action<IList<T>> mutate) {
  if (mutate == null) return this;
  var list = new List<T>(this);
  mutate(list);
  return new ImmutableList<T>(list);
}

现在不存在被用户误解的可能性，他们自然会掉进成功的坑里。

还有一个更新:

如果你仍然不喜欢提到可变列表，即使现在包含了它，你可以设计一个规范对象，它将指定或脚本，复制操作将如何转换它的列表。用法是一样的:

var list1 = new ImmutableList<string>("Hello");
// rules is a specification object, that takes commands to run in the copied collection
var list2 = list1.Copy(rules => rules.Append("World!"));

现在你可以对规则名称进行创新，你可以只公开你想要Copy支持的功能，而不是IList的全部功能。

对于链接的使用，你可以创建一个合理的构造函数(当然，它不会使用链接):

public ImmutableList(params T[] elements) ...

...

var list = new ImmutableList<string>("Hello", "immutable", "World");

或者在其他构造函数中使用相同的委托:

var list = new ImmutableList<string>(rules => 
  rules
    .Append("Hello")
    .Append("immutable")
    .Append("World")
);

这里假设规则。Append方法返回这个。

这是你最新的例子的样子:

var suite = new TestSuite<string, int>(x => x.Length);
var otherSuite = suite.Copy(rules => 
  rules
    .Append(x => Int32.Parse(x))
    .Append(x => x.GetHashCode())
);

扩展方法呢?在这种情况下，可以将其称为Join。作为一个扩展方法，用户应该知道它是一个静态方法，因此可能会让他们暂停一下，并鼓励他们查看返回值。同时，您拥有“实例”方法的可用性。

public static ImmutableList<T> Join(this ImmutableList<T> body, T tail)
{
    // add robust error checking in case either is null...
    return new ImmutableList<T>(body, tail);
}

再后来……

var list = new ImmutableList<string>().Join("Hello")
                                      .Join("Extensible")
                                      .Join("World");

我不太清楚发布多个答案的普遍行为，但这是一个有趣的问题，因为我认为命名是设计中的关键步骤，我的大脑一直在思考这个问题。