修改传入参数是否是反模式？[关闭]

我正在用Java编程，并且我总是使转换器像这样：

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

在新的工作场所中，模式是：

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

对我来说，这有点臭，因为我习惯于不更改传入的参数。此传入参数更改是反模式吗？它有一些严重的缺点吗？

这不是反模式，这是一个坏习惯。

反模式和纯粹的不良做法之间的区别在这里：反模式定义。

根据Bob叔叔的《清洁规范》，您展示的新工作场所风格是不道德的做法，是残留的或在OOP之前的时间。

参数最自然地解释为函数的输入。

强迫您检查功能签名的任何事情都等同于重复。这是一种认知障碍，应避免。在面向对象编程之前的日子里，有时必须要有输出参数。但是，输出参数的许多需求在OO语言中消失了

引用罗伯特·C·马丁（Robert C. Martin）的著名著作“清洁代码”：

应避免输出参数

函数应包含少量参数

第二种模式违反了两个规则，尤其是“输出参数”。从这个意义上讲，它比第一种模式差。

第二个习惯用法可以更快，因为调用者可以在长循环中重用一个变量，而不是每次迭代都创建新实例。

我一般不会使用它，但是例如。在游戏编程中它占有一席之地。例如，看一下JavaMonkey的Vector3f，许多操作允许传递应该修改的实例并作为结果返回。

我认为这些不是两个等效的代码段。在第一种情况下，您必须创建otherObject。您可以在第二个中修改现有实例。两者都有它的用途。代码气味会优先于另一种。

它确实取决于语言。

在Java中，第二种形式可能是反模式，但是某些语言对待传递参数的方式有所不同。在阿达和VHDL例如，代替通通过值或参考，参数可以具有模式in，out或in out。

修改in参数或读取out参数是错误的，但是对参数的任何更改in out都将传递回调用方。

因此，Ada中的两种形式（这些也是合法的VHDL）是

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

和

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

两者都有其用途。一个过程可以在多个Out参数中返回多个值，而一个函数只能返回一个结果。因为第二个参数的目的已在过程声明中明确说明，所以不能反对这种形式。我倾向于使用该功能以提高可读性。但是在某些情况下该过程会更好，例如，调用者已经创建了对象。

它确实看起来确实很臭，而且在没有看到更多上下文的情况下，无法确定地说。这样做可能有两个原因，尽管两者都有其他选择。

首先，这是实现部分转换的简洁方法，如果转换失败，则将结果保留为默认值。也就是说，您可能有以下内容：

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

当然，通常这是使用异常处理的。但是，即使出于某种原因需要避免出现异常，也有更好的方法可以做到这一点-TryParse模式是一种选择。

另一个原因是，这可能纯粹出于一致性原因，例如，它是公共API的一部分，无论出于何种原因，该方法都用于所有转换函数（例如具有多个输出的其他转换函数）。

Java不能很好地处理多个输出-它不能像某些语言一样具有仅输出参数，也不能像其他语言那样具有多个返回值-但即使如此，您仍然可以使用返回对象。

一致性原因相当la脚，但可悲的是，这可能是最常见的。

• 也许您工作场所（或代码库）的样式警察来自非Java背景并且不愿进行更改。
• 您的代码可能是这种风格更惯用的语言的移植。
• 您的组织可能需要在不同语言之间保持API的一致性，这是最低分母的样式（虽然很愚蠢，但即使对于Google也会发生）。
• 或者，该样式在遥远的过去更有意义，并演变为当前形式（例如，它本来可以是TryParse模式，但是一些善意的前任在发现根本没有检查任何值之后删除了返回值）。

第二种模式的优势在于，它迫使调用者对所创建的对象承担所有权和责任。毫无疑问，该方法是创建对象还是从可重用池中获取对象。呼叫者知道他们对新对象的生命周期和处置负责。

这种方法的缺点是：

1. 不能用作工厂方法，调用者必须知道所需的确切子类型OtherObject并预先构造它。
2. 如果这些参数来自，则不能与在其构造函数中需要参数的对象一起使用MyObject。OtherObject在不知情的情况下必须是可构造的MyObject。

答案基于我在c＃中的经验，我希望逻辑可以转换为Java。

鉴于语义的松散- myObjectToOtherObject同样可能意味着您将一些数据从第一个对象移到了第二个对象，或者将其完全重新转换，第二种方法似乎更合适。

但是，如果方法名是Convert（如果我们看“ ...进行转换”部分，应该是），那么我会说第二种方法没有任何意义。您不会将一个值转换为另一个已经存在的值IMO。