Question

假设我有以下方法：

public Stream GetMusic(string songTitle, string albumName) { ... }

我的一位同事确信这是一种糟糕的方法签名。他希望我使用一个Request对象，它会将方法签名转换为：

public Stream GetMusic(SongRequest request) { ... }

我真的没有看到这样做的意义。我看到的唯一好处是将来添加参数会更容易。我们不必更改方法签名，但仍然需要更改Request对象。

就个人而言，我认为这不是一个好主意。使用参数可以明确表示方法运行所需的内容。另外，这迫使我们不多创造另一个对象。

使用Request对象的优缺点是什么？您是否在项目中使用它以及为什么？

Answer 1

传递对象有一个主要优点 -

如果有一个对象用作参数，例如SongRequest，则对象可以负责自己的验证。这允许您显着简化使用该对象的每个方法的验证，因为您几乎只需要检查null，而不是检查每个参数。

此外，如果您有许多参数，生成单个对象通常会更简单。如果您发现需要多次重载来管理不同的参数组合，则尤其如此。

话虽如此，每种情况都是独一无二的。对于每种情况，我都不建议采用一种方法。

Answer 2

您正在使用GetMusic(...)方法获取数据。如果是这样，那么在没有真正需要的情况下使用其他实体可能需要付出太多努力。

实际上，在某种情况下，只有一个输入参数，您可以使用自定义类。但是如果该类是唯一可以使用的地方，那么如果类名称为SongSignature，则必须使用专门来使用此类，这是使用的不良做法“参数袋”，因为它的可读性很好。

此外，如果有人愚蠢地说SongSignature必须是一个结构，并且在该结构中有一个指向要在方法内部更改的数据的指针，那么指针永远不会真正改变，因为每次{{1}调用它，它将需要属性包的副本 。

即使它是一个类，你也必须将该类的访问器更改为GetMusic，并且通常这不是将参数传递给函数并从函数获取结果的最佳方法，因为你已经从该方法获得了一个流。

让我们假设以下情况：

如果在团队中，一个程序员用类public替换参数，则第二个程序员没有发现它被用作函数的参数（因为它在类的名称中运气信息），并且在下一次迭代中将它改为一个结构，第三个程序员以这种方式使用这个方法，它必须是一个类（例如在SongRequest中使用了类引用）...结果没有人真正做到了知道为什么有些东西不起作用，因为每个东西都有圆顶正确的东西......没有理由使用一个类来进行本地使用而不是隐式声明参数。

一般来说，你很有可能在将来遇到这种情况，因为：

您不是更改代码的人（即SongRequest）
有人可以查看代码并找到类'SongReqest'有用（因此情况更糟 - 从本地使用到全局使用类）
添加GetMusic类可以为你添加一个额外的依赖方法（有人改变这个类，很可能你的功能不会编译）
使用SongReuest作为SongRequest仅将其用作锁定类，如前所述。
使用这个类，你的方法可能永远不会与其他函数调用共享它的参数（出于什么原因？）
最后，仅使用property bag类来传递特定函数的参数，会产生额外的内存开销，因为如果经常调用此方法，一方面会产生大量不必要的对象在内存中必须进行垃圾收集，另一方面，如果很少使用这样的方法，创建一个类将几个变量传递给单个调用将是不切实际的

只有一个真正的理由使用类而不是两个字符串参数：程序员喜欢这样的调用，并希望使所有代码“比以前更漂亮”，更多monadic，尽管事实上这不是很实用，有用。

我永远不会建议你让代码看起来像这样，直到你想让它看起来更好。

通常，我认为使用自定义类传递函数的参数是一种不好的做法。

请求对象，有什么优缺点？

2 个答案: