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

发布于 2024-12-06 05:12:37 字数 433 浏览 3 评论 0原文

假设我有以下方法:

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

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

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

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

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

使用 Request 对象有哪些优点和缺点?您在项目中使用它吗?为什么?

Let's say I have the following method:

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

A colleague of mine is convinced that this a bad method signature. He would like me to use a Request object, which would transform the method signature into this:

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

I really don't see the point of doing that. The only benefit I see is that it will be easier to add parameters in the future. We won't have to change the method signature, but the Request object still have to change.

Personally, I don't think it is a good idea. Using parameters makes it explicit what the method requires to run. In addition, this force us to create another object for not much.

What are the pros and cons of using Request objects? Are you using it in your projects and why?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

凡间太子 2024-12-13 05:12:37

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

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

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

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

让我们假设以下情况:

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

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

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

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

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

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

You are getting data using GetMusic(...) method. If so, it whould probably too much effort to use an additional entity without really need.

Indeed, in a situation, where is only one input parameter, you can use a custom class. But if that class is the only place to use, so if SongSignature as the class name says, have to be used specifically for this class, that is a bad practice of using "parameter bags", because it lucks readability.

Additionally, if someone stupid says that SongSignature must be a structure, and in that structure there is a pointer to some data to be changed inside method, that pointer would never really changes because every time GetMusic is called, it will take a copy of a property bag.

Even if it is a class, you have to change the accessor for that class to public, and in general this is not the best method to pass an arguments forward to a function and getting results from a function, because you have already getting a stream from that method.

Let's assume the following situation:

If in a team one programmer replaces the parameters with a class SongRequest, second programmer did not find that it is used as a parameter to a functions (because it lucks info in a name of a class), and changed it to a structure on next iteration, third programmer used this method in such a way, that it have to be a class (for example have used class references inside SongRequest)... As a result no one did really knowns why something is not working because each of them have dome right thing... There is no excuse to use a class for a local usage instead of implicit declaration of parameters.

Generally you have a good chances to get such a situation in a future, because:

  • you are not the one who changes your code (i.e. GetMusic)
  • someone can review the code and find the class 'SongReqest' useful (so situation goes even worse - from a local usage to a global usage of a class)
  • adding the SongReuest class can add an additional dependencies for you method (is someone changes this class, most likely you founction will not compile)
  • using SongRequest as a property bag locks it usage only as as a class, as mentioned before.
  • using this class, you method would probably never share it parameters with other function calls (for what reason?)
  • finally, using SongRequest class only for passing parameters for a specific function, gives additional memory overhead footprint, because if this method is called often, at one hand, it will create a lot of unnecessary objects in memory have to be garbage collected, in the other hand, if such a method is used rarely, it will be simply not practical to create a class to pass several variables to a single call

There is only one real reason to use class instead of a two string arguments: you programmer likes such calls and wants to make all code "more beautiful than before", more monadic, despite the fact that this is not very practical and useful.

I would never advice you to make a code looks like this until you want to make it looks better.

Generally, I suppose that using a custom class for passing an arguments for a function is a bad practice.

我们只是彼此的过ke 2024-12-13 05:12:37

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

如果您有一个对象用作参数,例如 SongRequest,则该对象可以负责其自身的验证。这使您可以极大地简化使用该对象的每个方法中的验证,因为您几乎只需要检查 null,而不是检查每个参数。

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

话虽这么说,每种情况都是独特的。我不会在每种情况下推荐一种方法而不是另一种方法。

There is one major advantage to passing an object -

If you have an object used as the parameter, such as SongRequest, the object can be responsible for its own validation. This allows you to dramatically simplify the validation in each method that uses the object, as you pretty much only need to check for null, instead of checking each and every parameter.

In addition, if you have many parameters, it can often be simpler to generate a single object. This is especially true if you find you need multiple overloads to manage different combinations of parameters.

That being said, each situation is unique. I would not recommend one approach over the other for every situation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文