改变方法里面的参数值,这是一个反模式吗?

时间:2012-12-28 12:37:24

标签: c# anti-patterns

这样的事情

public void MyMethod(object parameter)
//....
    BuildSomething(parameter);
    BuildLayers(parameter);
    BuildOtherStuff(parameter);
}

public void BuildSomething(object parameter)
{
//...
    parameter.SomeProperty = "sadsd";
//...
}

如果这是反模式,它叫什么? 问题(可能)是您隐式更改参数并使用更改的值 我只是想知道这种反模式是什么

由于

3 个答案:

答案 0 :(得分:16)

这是side effect

这些通常都不好,被认为是代码气味,因为它很难推理和理解代码。

但是,这种模式有时很有用。

C#专门编纂了refout个关键字 ,以表明某种方法会产生副作用。

答案 1 :(得分:0)

我有不同的观点。

尽管在调试过程或代码可读性方面可能会引入更改参数值的小问题,但我将这种做法称为“反模式”并没有意义。

基于现代的OO语言设计,如Java或C#,我支持这样的想法:如果它是丑陋的,错误的或不推荐更改参​​数值,他们已经定义了类型参数作为实例的副本,而不是引用

不同意Oded的说法,我认为 ref out 关键字只应在你真正希望更改整个实例值的上下文中使用,完全取代。要使用其中一个关键字来告诉“嘿家伙,参数值可以在执行堆栈期间改变”对我来说听起来有点粗心。如果您的一个客户看到功能签名并且真的相信他可以替换整个东西怎么办? (在非预期行为的情况下)。

答案 2 :(得分:0)

假设parameter的类型不是object,而是包含可写属性或字段SomeProperty的类类型,那么当方法输入时,值parameter的{​​{1}}将是某个对象的标识(例如,自程序开始以来创建的459,192nd对象)。据我所知,该参数的值(意味着它引用的对象的身份)在整个方法中将继续保持相同。

更改传入参数的值(例如说parameter = someOtherObject)可能是代码气味,除非方法足够小以至于显而易见的是什么。