参数参数有什么不好？

我遇到的情况我认为只能通过使用ref参数来解决.但是,这意味着当我只需要5%的ref参数提供的功能时,将方法更改为始终接受ref参数.

这让我觉得"哇,疯了,必须找到另一种方式".我是傻瓜吗？ref参数可能导致哪些问题？

编辑

要求提供进一步的细节,我不认为它们与我的要求完全相关,但我们走了.

我想要保存一个新实例(将使用以后可能使用的ID进行更新)或检索与某些逻辑匹配的现有实例并更新它,保存它然后更改新实例的引用以指向现有的.

代码可能会更清晰:

protected override void BeforeSave(Log entity)
{
    var newLog = entity;

    var existingLog = (from log in repository.All()
                           where log.Stuff == newLog.Stuff 
                                 && log.Id != newLog.Id
                           select log).SingleOrDefault();

    if (existingLog != null)
    {
        // update the time
        existingLog.SomeValue = entity.SomeValue;
        // remove the reference to the new entity
        entity = existingLog;
    }
}

// called from base class which usually does nothing before save
public void Save(TEntity entity)
{
    var report = validator.Validate(entity);

    if (report.ValidationPassed)
    {
        BeforeSave(entity);
        repository.Save(entity);
    }
    else
    {
        throw new ValidationException { Report = report };
    }
}

事实上,我只会为基类中的一个子(目前为止)添加它,以防止我使用重载(因为我必须复制Save方法).我也有问题,我需要强制他们在这个实例中使用ref版本,否则事情将无法按预期工作.

你能加一个超载吗？有一个没有ref参数的签名,还有一个签名.

参数参数可能很有用,我很高兴它们存在于C#中,但它们不应该被不加思索地使用.通常,如果方法有效地返回两个值,则将方法拆分为两个部分或将两个值封装在单个类型中会更好.这些都不包括每一个案例 - 肯定有时候什么时候ref是最好的选择.

也许对这个5%的情况使用重载函数并保持其他函数不变.

不必要的ref参数可能导致糟糕的设计模式,但如果您有特定需求,那么这样做没有问题.

如果您将.NET Framework作为人们对API期望的晴雨表,请考虑几乎所有String方法都返回修改后的值,但保持传递的参数不变.例如,String.Trim()返回修剪过的String - 它不会修剪作为参数传入的String.

现在,显然,只有当您愿意将返回值放入API时,这才是可行的.此外,如果您的函数已经返回一个值,则会遇到创建包含原始返回值以及新更改的对象的自定义结构的令人讨厌的可能性.

最终,这取决于您以及如何记录您的API.我根据自己的经验发现,我的同事们往往希望我的函数"像.NET Framework函数一样".:)