blocks|key|1089969|text|最好的做法是重构。这些对象意味着它们应该被传递给这个方法吗？是否应该将它们封装到单个对象中？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1089970|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Good practice would be to refactor. What about these objects means that they should be passed in to this method? Should they be encapsulated into a single object?

blocks|key|1305251|text|您可以创建一个类来保存这些数据。需要足够有意义，但比使用map+(OMG)要好得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1305252|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You could create a class to hold that data. Needs to be meaningful enough though, but much better than using a map (OMG).

blocks|key|1090094|text|使用带有神奇字符串键的map不是一个好主意。您会丢失任何编译时检查，并且不清楚所需的参数是什么。您需要编写非常完整的文档来弥补这一点。不看代码，几周后你能记住这些字符串是什么吗？如果你打错了怎么办？使用错误的类型？在运行代码之前，您不会发现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090095|相反，使用模型。创建一个类，它将成为所有这些参数的容器。这样就保证了Java的类型安全。您还可以将该对象传递给其他方法，将其放入集合中，等等。|1090096|当然，如果这组参数没有在其他地方使用或传递，那么专用模型可能会被夸大。有一个平衡需要达成，所以使用常识。|1090097|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Using a map with magical String keys is a bad idea. You lose any compile time checking, and it's really unclear what the required parameters are. You'd need to write very complete documentation to make up for it. Will you remember in a few weeks what those Strings are without looking at the code? What if you made a typo? Use the wrong type? You won't find out until you run the code.

Instead use a model. Make a class which will be a container for all those parameters. That way you keep the type safety of Java. You can also pass that object around to other methods, put it in collections, etc.

Of course if the set of parameters isn't used elsewhere or passed around, a dedicated model may be overkill. There's a balance to be struck, so use common sense.

blocks|key|1090169|text|使用Map是清除调用签名的一种简单方法，但是您还有另一个问题。您需要查看该方法的主体，以了解该方法在该Map中需要什么、键名是什么或值具有什么类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090170|一种更简洁的方法是将所有参数分组到一个对象bean中，但这仍然不能完全解决问题。|1090171|您在这里遇到的是设计问题。当一个方法的参数超过7个时，你就会在记住它们所代表的内容以及它们的顺序时遇到问题。从这里开始，你仅仅通过以错误的参数顺序调用该方法就会得到很多错误。|1090172|你需要一个更好的应用程序设计，而不是发送大量参数的最佳实践。|1090173|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Using a Map is a simple way to clean the call signature but then you have another problem. You need to look inside the method's body to see what the method expects in that Map, what are the key names or what types the values have.

A cleaner way would be to group all parameters in an object bean but that still does not fix the problem entirely.

What you have here is a design issue. With more than 7 parameters to a method you will start to have problems remembering what they represent and what order they have. From here you will get lots of bugs just by calling the method in wrong parameter order. 

You need a better design of the app not a best practice to send lots of parameters.

blocks|key|1090219|text|有一种模式叫做Parameter+object。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1090220|我的想法是用一个对象代替所有的参数。现在，即使您稍后需要添加参数，也只需将其添加到对象中。方法接口保持不变。|1090221|entityMap|0|LINK|mutability|MUTABLE|url|http://sourcemaking.com/refactoring/introduce-parameter-object^0|7|G|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

There is a pattern called as <a href="http://sourcemaking.com/refactoring/introduce-parameter-object" rel="noreferrer">Parameter object</a>. 
Idea is to use one object in place of all the parameters. Now even if you need to add parameters later, you just need to add it to the object. The method interface remains same.

blocks|key|1090295|text|首先，我会尝试重构该方法。如果它使用了那么多参数，那么无论如何它都可能太长了。分解它既可以改进代码，又可以减少每个方法的参数数量。您还可以将整个操作重构为它自己的类。其次，我会寻找使用相同参数列表的相同(或超集)的其他实例。如果您有多个实例，则可能表示这些属性属于一起。在这种情况下，创建一个类来保存参数并使用它。最后，我将评估参数的数量是否值得创建一个map对象来提高代码的可读性。我认为这是一个个人电话--这种解决方案的每一种方式都有痛苦，折衷点可能有所不同。对于六个参数，我可能不会这么做。对于10个方法，我可能会这样做(如果没有其他方法先起作用的话)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090296|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

First, I'd try to refactor the method. If it's using that many parameters it may be too long any way. Breaking it down would both improve the code and potentially reduce the number of parameters to each method. You might also be able to refactor the entire operation to its own class. Second, I'd look for other instances where I'm using the same (or superset) of the same parameter list. If you have multiple instances, then it likely signals that these properties belong together. In that case, create a class to hold the parameters and use it. Lastly, I'd evaluate whether the number of parameters makes it worth creating a map object to improve code readability. I think this is a personal call -- there is pain each way with this solution and where the trade-off point is may differ. For six parameters I probably wouldn't do it. For 10 I probably would (if none of the other methods worked first).

blocks|key|1090355|text|创建一个bean类，设置所有参数(setter方法)并将此bean对象传递给该方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090356|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Create a bean class, and set the all parameters (setter method) and pass this bean object to the method.

blocks|key|1305658|text|这通常表明你的类承担了不止一个责任(即，你的类做了太多的事情)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1305659|请参阅The+Single+Responsibility+Principle|offset|length|1305660|以获取更多详细信息。|1305661|entityMap|0|LINK|mutability|MUTABLE|url|http://www.objectmentor.com/resources/articles/srp.pdf^0|0|3|Z|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

This is often an indication that your class holds more than one responsibility (i.e., your class does TOO much).

See <a href="http://www.objectmentor.com/resources/articles/srp.pdf" rel="nofollow noreferrer">The Single Responsibility Principle</a>

for further details.

blocks|key|1305735|text|如果您传递的参数太多，请尝试重构该方法。也许它正在做很多它不应该做的事情。如果不是这样，请尝试用单个类替换参数。通过这种方式，您可以将所有内容封装在单个类实例中，并传递实例而不是参数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1305736|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you are passing too many parameters then try to refactor the method. Maybe it is doing a lot of things that it is not suppose to do. If that is not the case then try substituting the parameters with a single class. This way you can encapsulate everything in a single class instance and pass the instance around and not the parameters.

blocks|key|1090552|text|如果您有许多可选参数，您可以创建fluent+API:将单个方法替换为方法链|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090553|exportWithParams().datesBetween(date1,date2)
++++++++++++++++++.format("xml")
++++++++++++++++++.columns("id","name","phone")
++++++++++++++++++.table("angry_robots")
++++++++++++++++++.invoke();|code-block|syntax|javascript|1090554|使用静态导入，您可以创建内部流畅API：|1090555|...+.datesBetween(from(date1).to(date2))+...|1090556|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If you have many optional parameters you can create fluent API: replace single method with the chain of methods

<pre><code>exportWithParams().datesBetween(date1,date2)
 .format("xml")
 .columns("id","name","phone")
 .table("angry_robots")
 .invoke();
</code></pre>

Using static import you can create inner fluent APIs:

<pre><code>... .datesBetween(from(date1).to(date2)) ...
</code></pre>

blocks|key|1305839|text|..。Bob是你的叔叔:用于对象创建的简单的API！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1305840|https://projectlombok.org/features/Builder|offset|length|1305841|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|16|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

... and Bob's your uncle: No-hassle fancy-pants APIs for object creation!
<a href="https://projectlombok.org/features/Builder" rel="nofollow noreferrer">https://projectlombok.org/features/Builder</a>

Occasionally , we have to write methods that receive many many arguments , for example :

<pre><code>public void doSomething(Object objA , Object objectB ,Date date1 ,Date date2 ,String str1 ,String str2 )
{
}
</code></pre>

When I encounter this kind of problem , I often encapsulate arguments into a map.

<pre><code>Map&lt;Object,Object&gt; params = new HashMap&lt;Object,Object&gt;();
params.put("objA",ObjA) ;

......

public void doSomething(Map&lt;Object,Object&gt; params)
{
 // extracting params 
 Object objA = (Object)params.get("objA");
 ......
 }
</code></pre>

This is not a good practice , encapsulate params into a map is totally a waste of efficiency.
The good thing is , the clean signature , easy to add other params with fewest modification .
what's the best practice for this kind of problem ?

Best practice for passing many arguments to method?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有时，我们必须编写接收许多参数的方法，例如：public void doSomething(Object objA , Object objectB ,Date date1 ,Date date2 ,String str1 ,String str2 ){}当我遇到这类问题时，我通常会将参数封装到映射中。Map<Obje...

问将许多参数传递给方法的最佳实践？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将许多参数传递给方法的最佳实践？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将许多参数传递给方法的最佳实践？
EN