Questions tagged «parameters»

参数对于任何非平凡的程序都很重要,有助于使其成为通用且由数据驱动。参数通常是函数参数,但也可以是配置的一部分。


7
将对象传递到更改对象的方法中,这是常见的(反)模式吗?
我正在阅读Martin Fowler的《重构》一书中的常见代码气味。在这种情况下,我想知道我在代码库中看到的一种模式,并且可以客观地将其视为一种反模式。 模式是一种将对象作为参数传递给一个或多个方法的模式,所有这些方法都会更改对象的状态,但是没有一个返回对象。因此,它依赖于C#/。NET(在这种情况下)的按引用传递特性。 var something = new Thing(); // ... Foo(something); int result = Bar(something, 42); Baz(something); 我发现(尤其是方法名称不正确时),我需要研究此类方法以了解对象状态是否已更改。由于我需要跟踪调用堆栈的多个级别,因此这会使代码理解更加复杂。 我想建议改进此类代码,以返回具有新状态的另一个(克隆的)对象,或在调用站点更改该对象所需的任何操作。 var something1 = new Thing(); // ... // Let's return a new instance of Thing var something2 = Foo(something1); // Let's use out param to 'return' other info about the operation …

5
将对象两次传递给相同的方法还是与合并的接口合并?
我有一种方法,可以在与数字板交谈后创建数据文件: CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer) 这里boardFileAccess和boardMeasurer是相同的实例Board对象,同时实现了IFileAccess和IMeasurer。IMeasurer在这种情况下,仅用于一种方法,该方法将使板上的一个引脚处于活动状态以进行简单的测量。然后,使用将该测量的数据本地存储在板上IFileAccess。Board位于一个单独的项目中。 我得出的结论CreateDataFile是,通过快速测量然后存储数据来做一件事,对于其他使用此代码然后必须进行测量并写入文件的人来说,使用同一方法进行这两种操作更直观作为单独的方法调用。 对我来说,将同一对象两次传递给方法似乎很尴尬。我认为做一个本地接口IDataFileCreator,可以扩展IFileAccess和IMeasurer再有一个包含一个实现Board的实例,将只需要调用所需的Board方法。考虑到同一板对象将始终用于测量和文件写入,将同一对象两次传递给方法是否是一种不好的做法?如果是这样,使用本地接口和实现是否是合适的解决方案?

3
ref和out在运行时之间有什么区别?
C#提供ref和out关键字,以使参数通过引用传递。两者的语义非常相似。唯一的区别在于标记变量的初始化: ref要求在将变量传递给函数之前进行初始化,out而不是。 out要求变量在函数内部初始化,ref不需要。 这两个关键字的用例也几乎相同,它们的使用频率太高了,我相信这是代码的味道(尽管有诸如TryParse和TryGetValue模式之类的有效用例)。 因此,有人可以解释一下,为什么C#中有两个非常相似的工具用于如此狭窄的用例? 另外,在MSDN上,它们具有不同的运行时行为: 尽管ref和out关键字导致不同的运行时行为,但在编译时它们不被视为方法签名的一部分。 它们的运行时行为有何不同? 结论 这两个答案看起来都是正确的,谢谢你们。我接受jmoreno是因为它更明确。

7
函数只返回不变的参数,没用吗?
我刚刚在我正在工作的项目中找到此功能: -- Just returns the text unchanged. -- Note: <text> may be nil, function must return nil in that case! function Widget:wtr(text) return text end 太可悲的是,编码器不再在公司工作。为什么要使一个函数什么都不做,但是返回调用它的参数呢? 这种功能有什么用,在本例中未指定,但在任何情况下都没有用? 由于 function aFunction(parameter) return parameter end 结束于 aFunction(parameter) == parameter 我为什么要写这样的东西 aFunction(parameter) == whatIWantToCheck 代替 parameter == whatIWantToCheck ?

2
参数化方法与全局变量
当我的代码开始增长时,我有一个很简单的问题困扰了我一段时间。 当参数经过嵌套函数调用的长路径时,是否应将其替换为全局变量? 我知道全局环境会使程序的状态不可预测,因为许多函数可以修改共享变量,但是全局空间仍然使事情变得如此容易。 让我解释一下自己: functionA(){ x = something functionB(x) } functionB(x){ functionC(x) } functionC(x){ finallyDoSomethingWithX(x) } finallyDoSomethingWithX(x){ x += 1 //Very dummy example ignoring pass by value, not reference. } 取而代之: globalX; functionA(){ globalX = something functionB() } ... ... ... finallyDoSomethingWithX(){ globalX += 1 } 我觉得第二种方式给程序带来了很大的自由度,因为参数很容易累积,并且有时在必须重用代码时可能会受到很大的限制,但是与此同时,我觉得函数在与变量相关时会失去其模块化在全球环境中,例如当我想finallyDoSomethingWithX使用另一个变量tha 时,它也失去了可重用性globalX。 我认为这是发生在我身上的原因,因为我实际上不是在使用设计模式,因为我使用Javascript进行编程,对我而言,这感觉像是针对中型项目的所有语言的一种脚本交易。 有什么建议吗?模式?如果需要,我可以更具体。

2
创建唯一目的是隐式转换为另一个类的类是否不好?
想象一下一种情况,我们正在使用一个允许您创建Circle对象的库,您可以在其中指定半径和圆心来定义它。但是,由于某些原因,它也需要一个必需的flavour参数。现在,我们确实需要Circle在自己的应用程序中使用,但是出于我的应用程序的目的,我可以将风味设置为Flavours.Cardboard每次。 为了“解决”这一问题,我Circle在另一个命名空间中创建了自己的类,该命名空间仅将radius和center作为参数,但具有一个隐式转换器,可以直接转换为Circle仅创建Circle(this.radius, this.center, Flavours.Cardboard)对象的外部库类。因此,在任何需要其他类型的的地方Circle,我都会进行自动转换。 创建这样一个类的后果是什么?有更好的解决方案吗?如果我的应用程序是在此外部库的基础上构建的供其他程序员使用的API,会有所不同吗?

2
标识符vs域对象作为方法参数
是否有客观的论据支持或反对使用对象vs唯一ID作为方法/函数参数?(以及其他对象的成员?)。特别是在静态类型语言(C#/ Java / Scala)的上下文中 对象本身的优点: 更多类型安全的调用。使用ID时,存在参数错误排序的风险。尽管可以通过为每个仅保留该类ID的类保留一个“ mini”类来缓解这种情况。 从持久中获得一次,无需再次获得 使用ID时,如果id类型发生更改,例如int-> long,则将要求全面更改,并且可能会出错。.(courtsey:https ://softwareengineering.stackexchange.com/a/284734/145808 ) 使用ID的优点: 在大多数情况下,不需要唯一的对象,只需要uniqueid即可,因此拥有ID可以节省从持久性获取ID的时间。 据我所知,将这些技术混合使用既有弊又无利。 鉴于这是一个具体定义的问题,我希望有客观的答案,而不是-“我认为”或“我喜欢”类型... :-)。 编辑:评论者建议的上下文-唯一的限制是静态类型的语言。该应用程序是一个通用应用程序,尽管也很高兴能够根据特定的使用场景获得答案。 编辑:更多的上下文。说我有一个图书管理系统。我的模型是: Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member } Member: {id: Int, name: String} Table- wishlist: { isbn: String, memberId: Int} Table- borrows: { id: Int, memberId: Int} Method: …

6
字段与方法参数
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我刚开始写一些新的类,然后发现我添加了很多严格不需要的方法参数。这是为了避免在某些方法调用特定的类中具有状态,而不是成为类的常规配置或依赖性,这是一种习惯。 这样做意味着许多没有参数的方法最终只能得到一,二或三。 我想听听您对这个折衷方案的看法,以及如何决定在何种情况下采取哪种方法? 由于在描述代码时,代码通常比英语更容易理解,因此我创建了一个包含两个变体的小知识点:https : //gist.github.com/JeroenDeDauw/6525656
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.