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

Question

假设我有以下方法:

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

我的一位同事确信这是一个错误的方法签名。他希望我使用 Request 对象，它将方法签名转换为:

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

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

就我个人而言，我认为这不是一个好主意。使用参数可以明确该方法需要运行什么。此外，这迫使我们以不多的钱创建另一个对象。

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

Answer 1

您正在使用 GetMusic(...) 获取数据方法。如果是这样，那么在没有真正需要的情况下使用额外的实体可能会花费太多精力。

确实，在只有一个输入参数的情况下，您可以使用自定义类。但是如果那个类是唯一可以使用的地方，那么如果 SongSignature正如类名所说，必须专门用于此类，这是使用“参数包” 的不良做法，因为它的可读性不好。

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

即使是一个类，你也得把那个类的accessor改成public ，并且通常这不是将参数传递给函数并从函数获取结果的最佳方法，因为您已经从该方法获取了流。

让我们假设以下情况:

如果在一个团队中，一名程序员用类替换参数 SongRequest ，第二个程序员没有发现它被用作函数的参数(因为它在类的名称中幸运信息)，并在下一次迭代中将其更改为结构，第三个程序员以这种方式使用此方法，即它必须是一个类(例如在 SongRequest 中使用了类引用)...结果没有人真正知道为什么某些东西不起作用，因为它们每个都有圆顶正确的东西。 .. 没有理由将类用于局部用法而不是参数的隐式声明。

一般来说，您将来很有可能遇到这种情况，因为:

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

使用类而不是两个字符串参数只有一个真正的原因:你的程序员喜欢这样的调用并且想让所有代码“比以前更漂亮”，更单子(monad)化，尽管这不是很实用并且有用。

除非你想让它看起来更好，否则我绝不会建议你把代码写成这样。

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