应该传递一次性对象吗？

Question

在代码审查中，我的同事更改了我的代码，将一个Stream作为参数传递。他说这样可以确保调用者清楚地知道处理对象的责任。从某种意义上说，我能够理解。我也希望对象创建者负责清理。

另一方面，两种方法都没有使需要使用using更加清晰。我也更喜欢更简单的方法调用。

接下来是需要翻译的内容：Take

    public static TextReader Serialize<T>(T obj) where T: new()
    {
        if (obj == null) throw new ArgumentNullException("obj");
        return Serialize<T>(obj, null);
    }

VS

    public static void Serialize<T>(T obj, TextWriter outbound) where T : new()
    {
        if (obj == null) throw new ArgumentNullException("obj");
        Serialize<T>(obj, outbound, null);
    }

是否有任何技术原因需要添加额外的参数？

- P.Brian.Mackey

---

比如说，如果我们从.NET Framework本身中借鉴一些经验，比如 XmlSerializer，通常会将流作为参数传递。 - mellamokb

可能是一个问题，需要在http://codereview.stackexchange.com/上进行代码审查。 - MattDavey

Answer 1

这严格取决于你的代码架构。

我个人喜欢第二种方法（尽管它添加了一个参数），其中函数定义表明它不会关闭/释放流，但由调用者决定。

如果你将在相同的流上调用相同的函数，这非常有用，因为如果你想象每个函数调用都会关闭和重新打开流，那么它就会变成资源消耗操作。

- Tigran

Answer 2

你可能已经打开了一个TextWriter。这就是为什么我更喜欢第二个版本。此外，它减少了Serialize方法的作用域：它进行序列化，但不会打开任何东西。打开是不同的问题。

- usr

Answer 3

随着项目的发展，维护代码的程序员可能不记得关闭流是调用代码的责任（特别是在非平凡情况下）。调用者必须依靠文档来做正确的事情，而每个人都会阅读文档，对吧？ ;)

第二种方法更好地平衡资源。它使责任分离更加清晰。

- Branko Dimitrijevic

Answer 4

重载的Serialize-T方法会创建流吗？如果是这样，我更喜欢#1，因为它使“using”更简单：

using (var stream = Serialize(a_T)))
{
    // Do something else with the stream?
} 

另一方面，如果调用者提供流，则最好是使用选项2传递一个流。

- n8wrl