传递单个对象与传递多个参数 [英] Passing single object vs. passing multiple parameters
问题描述
假设我有以下内容
Class A {
Foo getFoo();
Bar getBar();
Baz getBaz();
}
我需要定义一个函数doStuff，该函数使用一个对象的Foo，Bar，Baz，并执行一些操作
我在哪种实现doStuff的方法之间比较挣扎(假设将doStuff放在类A内是不希望的)
方法A
void doStuff(Foo foo, Bar bar, Baz baz)
{
//some operation
}
或
方法B
void doStuff(A a)
{
Foo foo = a.getFoo();
Bar bar = a.getBar();
Baz baz = a.getBaz();
//some operation
}
据我所知， (+优点，-缺点)
方法A
+很明显doStuff()可以对哪些参数进行操作
-易受参数列表影响，更容易出现用户错误
方法B
+简单易用的方法
+似乎更具可扩展性(?)
-创建对类A
谁能对这两种方法的优缺点分享更多见解?
方法A(裸参数)始终具有以下优点:
- 它要求方法作者键入更少的内容，因为他们不必实现参数对象，
- 它要求方法调用者键入的内容较少，因为它们不必实例化参数对象
- 它的性能更好，因为无需构造参数对象并可以进行垃圾回收
- 读者可以单独从方法签名中看到各个参数(但这是一把双刃剑；请参见下文)
方法B(参数对象)在以下情况下具有优势
- 参数作为一个组具有域的含义，因此可以给Parameter Object一个解释该含义的名称，从而使读者不必阅读和理解组中的每个成员以及它们之间的关系
- 参数列表使用了多种方法，因此在每种方法中使用Parameter Object可以减少重复
- 参数列表中的值作为一组在多个方法之间传递，当它们可以作为单个参数对象传递时更容易
- 某些值组合无效；参数对象可以阻止这些组合
- 某些值是可选的，可以由参数对象提供，而不是(取决于您的语言)默认参数值或重载方法提供的值
- 存在多个相同类型的参数，因此更容易发生值交换错误(尽管在这种情况下，使用Parameter Object并不会更好) 具有与该方法相同的参数列表的构造函数)
参数对象引入了一个新的依赖关系，调用方和被调用方都依赖于此，这并不是什么缺点，因为它是一个简单的类，没有自己的依赖项.
所以，参数对象是
- 对于单个参数几乎永远都不值得，有时对于两个参数的方法也不值得(例如，Point通常优于x，y)，有时却不值得，并且对于三个或更多个参数的帮助越来越大
- 当更多方法使用相同的参数列表时，该功能会越来越有用
Suppose I have the following
Class A {
Foo getFoo();
Bar getBar();
Baz getBaz();
}
And I need to define a function doStuff that uses Foo, Bar, Baz of one object and does some stuff
I'm struggling between which method of implementing doStuff is better (suppose it would be undesirable to place doStuff inside class A)
Method A
void doStuff(Foo foo, Bar bar, Baz baz)
{
//some operation
}
or
Method B
void doStuff(A a)
{
Foo foo = a.getFoo();
Bar bar = a.getBar();
Baz baz = a.getBaz();
//some operation
}
To my limited knowledge, (+ pros, - cons)
Method A
+It is clear exactly what parameters doStuff() operates on
-Susceptible to long parameter lists and more susceptible to user mistakes
Method B
+Simple, easy to use method
+Seems more extensible (?)
-Creates unnecessary dependency towards class A
Can anyone share additional insight towards the pros and cons of these two methods?
Method A (naked parameters) always has the advantages that
- it requires the method author to type less, since they don't have to implement a Parameter Object,
- it requires the method caller to type less, since they don't have to instantiate a Parameter Object
- it performs better, since no Parameter Object has to be constructed and garbage collected
- the reader can see what the individual parameters are from the method signature alone (but this is a double-edged sword; see below)
Method B (Parameter Object) has advantages when
- the parameters have domain meaning as a group, so the Parameter Object can be given a name that explains that meaning, saving the reader from having to read and understand each member of the group and how they relate
- the parameter list is used in more than one method, so using the Parameter Object in each reduces duplication
- the values in the parameter list are passed around among multiple methods as a group, which is easier when they can be passed as a single Parameter Object
- some combinations of values are invalid; the Parameter Object can prevent those combinations
- some values are optional, which can be provided by the Parameter Object instead of (depending on your language) default parameter values or overloaded methods
- there is more than one parameter of the same type, making value-swapping errors more likely (although a Parameter Object is not better in this case if it has a constructor with the same parameter list as the method)
That the Parameter Object introduces a new dependency on which caller and callee depend is not much of a disadvantage, since it is a simple class with no dependencies of its own.
So, Parameter Object is
- almost never worthwhile for a single parameter, sometimes worthwhile for a two-parameter method (e.g. Point is usually better than x, y) and sometimes not, and increasingly helpful with three and more parameters
- increasingly helpful when more methods use the same parameter list
这篇关于传递单个对象与传递多个参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
