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