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

Question

假设我有以下方法:

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

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

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

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

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

使用Request对象的优缺点是什么？你在项目中使用它,为什么？

Answer 1

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

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

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

即使它是一个类，您也必须将该类的访问器更改为public，并且通常这不是将参数转发给函数并从函数获取结果的最佳方法，因为您已经从那个方法。

让我们假设以下情况：

如果在团队中，一个程序员用类替换参数SongRequest，第二个程序员没有发现它被用作函数的参数（因为它幸运地包含类名称中的信息），并在下一次迭代时将其更改为结构，第三个程序员以这样的方式使用这个方法，它必须是一个类（例如在内部使用了类引用SongRequest）...结果没有人真正知道为什么有些东西不起作用，因为他们每个人都有圆顶权利事情...没有理由使用类来进行本地使用而不是隐式声明参数。

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

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

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

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

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