请求对象，有什么优缺点？
假设我有以下方法：
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您正在使用
GetMusic(...)方法获取数据。如果是这样，那么在没有真正需要的情况下使用额外的实体可能会花费太多精力。事实上，在只有一个输入参数的情况下，您可以使用自定义类。但是，如果该类是唯一使用的地方，那么如果
SongSignature正如类名所示，必须专门用于该类，这是一种不好的做法“参数包”，因为它有利于可读性。此外，如果有人愚蠢地说
SongSignature必须是一个结构，并且在该结构中有一个指向方法内部要更改的某些数据的指针，则该指针永远不会真正更改，因为每次GetMusic被调用时，它将获取属性包的副本。即使它是一个类，您也必须将该类的访问器更改为 public，通常这不是将参数传递给函数并从函数获取结果的最佳方法，因为您已经从该方法中获取了流。
让我们假设以下情况：
如果在团队中，一个程序员用类
SongRequest替换参数，第二个程序员没有发现它被用作函数的参数（因为它幸运的是名称中的信息）类），并在下一次迭代时将其更改为结构，第三个程序员以这样的方式使用此方法，即它必须是一个类（例如在SongRequest中使用了类引用）。 .. 结果没有人真正知道为什么会发生这样的事情不起作用，因为它们每个都有圆顶正确的东西...没有理由使用类来进行本地使用而不是隐式声明参数。一般来说，您将来很有可能遇到这种情况，因为：
GetMusic），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
SongSignatureas 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
SongSignaturemust 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 timeGetMusicis 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 insideSongRequest)... 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:
GetMusic)SongReuestclass can add an additional dependencies for you method (is someone changes this class, most likely you founction will not compile)SongRequestas aproperty baglocks it usage only as as a class, as mentioned before.SongRequestclass 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 callThere 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.
传递对象有一个主要优点 -
如果您有一个对象用作参数，例如
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.