我会给你一个关于寻路的例子。当你想找到一条路径时，你可以选择一个最终目的地，一个初始位置并找到两者之间最快的路径，或者你可以定义第一个位置，让算法显示你可以完成的每条路径，或者你可以想模拟这个进行测试，然后说出最终目的地并假设您“传送”到那里，依此类推。很明显，功能是一样的：寻找路径。但是参数可能因实现而异。我搜索了很多，找到了很多解决方案：摆脱接口，将所有参数作为实现中的字段，使用访问者模式......
但是我想从你们那里知道将每个可能的参数（而不是状态）放在一个对象中（我们称之为 MovePreferences）并让每个实现都获取它需要的东西的缺点是什么。当然，您可能需要另一个实现，它以您没想到的参数作为参数，您将需要更改 MovePreferences，但这听起来不错，因为您只会向其中添加方法，而不是重构任何现有方法。即使此 MovePreferences 不是我的域的对象，我仍然很想这样做。你怎么看？
（如果您对此问题有更好的解决方案，请随时将其添加到您的答案中。）
您要问的问题实际上是为什么根本没有接口，不，为什么没有任何上下文概念，而不是“我需要什么？” 我认为这个问题的答案非常简单：使用共享全局状态进行编程对您（程序员）来说很容易，并且一旦他们必须合并不同的功能、针对不同的客户、渲染增强等，很快就会变成其他所有人的漩涡。
现在，光谱的另一端是 DbC 论点：每个单独的接口都必须是一个高度约束的合约，它不仅将交换的知识保持在绝对最低限度，而且使混乱的可能性最小化。
坦率地说，这就是依赖注入会很快变成一团糟的原因之一：一旦出现这样的设计问题，人们就会开始注入更多的“对象”，通常只是为了访问一个属性，其范围可能不会与本次操作的范围相同。【不一样的噩梦。】
不幸的是，您的问题中几乎没有任何信息。我认为可以正确地模拟路线的概念吗？当然。这听起来不是很有挑战性。这里有一些想法：
创建一个名为 Route 的类，该类具有起点和终点。然后是遍历的集合。这里的想法是，路线可以完全忽略某人如何从 a 点到达 b 点的概念，其中遍历可能包含有关道路、交通、关闭等信息。然后你的模拟案例里面可能没有遍历。
另一种选择是使 Route 成为一个Composite，这样每次旅行都被视为各个部分的串连。这就是通常呈现路线的方式：在 2 South 行驶 2 英里，退出，在 Santa Monica Boulevard 向东行驶 3 英里，等等。在这种情况下，您可以只拥有没有子节点的 Routes。
最后，您可能需要创建模式。也许是Builder。这也简化了模拟事情，因为您可以只创建一个模拟构建器并让它构建包含您需要的任何内容的路由。
组合 Composite 和 Builder 的另一个优点是，您可以创建一个构建器，可以通过尝试仅改进令人不安的子段来从现有路由构建新 Route，例如，它获得的交通信息表明 2S 很慢，它可以替换那一段，并展示它的新路线。
考虑一个例子，
假设 5 个参数被封装在一个对象中并传递给 3 个方法。
如果对象的结构发生变化，那么我们需要为所有 3 种方法运行测试用例。相反，如果该方法只接受它们需要的参数，则不需要对其进行测试。
我看到的唯一问题是测试工作量的增加
其次，如果您传递的参数多于方法实际需要的参数，您自然会违反单一职责原则 (SRP)。