我在解决这个问题时遇到了一些困难。对于不同类型，如何组织遍历关系以转换为不同类型的方法有哪些注意事项？
例如，虽然对精确建模持宽容态度，但想象有3个类在彼此之间具有多对多关系：Car，Garage和ParkingPass。
我将使用伪Java语法，但我不认为这是特定于语言的（或者甚至是OOP特定的，尽管可能更具相关性）。如果有人想知道汽车可以停放的车库，以下方法似乎等效：
询问Car物品的车库：
Car {
Collection<Garage> getGarages();
}
向车辆的Garage对象询问车辆：
Garage {
Collection<Garage> for(Car);
}
无论哪种方式，对象都需要通过ParkingPass类来解析关系映射，因此一个对象与另一个对象之间没有直接转换。
查看像Java Arrays.asList这样的例子（它使用与类大致相同的类型的参数，并生成不同的类），执行Car.getGarages()方法似乎是合理的。或者，查看Guava的ImmutableList.of，它接受一个“不同”类型的参数，并返回一个与类相同类型的值。
是否有最佳实践指导如何确定放置方法的位置？可能的解决方案可能包括：
所有这些方法的常见失败是排列问题 - 如果您的类形成高度连接的图形，无论选择哪种解决方案都会变大。
答案 0 :(得分：1)
从OO的角度来看，自然而然地要问Car它可以停放哪些车库.OTOH， 非常自然地要求 a Garage关于此问题，因为它要求Garage实例了解其他车库的知识。
答案 1 :(得分：1)
在这里询问Car是更好的解决方案，但它取决于语义，你将如何实际考虑模型。您还可以引入两种方法，一种方法只是询问另一种方法的实际值。所以问题是哪种方法是实际的信息来源。
对于这个特殊情况，为什么你不会将ParkingPass建模为一个类，它实际上会提供它自己包含的信息。
class ParkingPass {
Collection<Garage> for(Car);
}
这对我来说似乎是正确的做法。
答案 2 :(得分：1)
我不认为如何组织方法的问题可以用＆＃34;回复类型＆＃34;，＆＃34;通过参数＆＃34;来回答。相反，我认为方法所属的地方（以及如何组织代码）总是取决于代码所代表的模型，所以问题应该问自己：代码怎么样？最能代表我试图实施的模型吗？。看到你问这个问题，这可能是你的目标，所以我认为我们已经就此达成一致。但请允许我详细说明。
让我们以汽车和车库为例。所以我们想知道一辆车可以停放的车库。谁来决定一辆车是否可以停放在车库里？我想说，最终，车库决定是否允许容纳汽车，所以在车库类中设置一种确定是否允许汽车停在那里的方法是有意义的。车库。在这取决于什么条件，可能是停车证，车牌，它的颜色或其他什么，是车库唯一关注的问题。
但是现在我们拥有的停车证可能会影响我们是否可以进入车库。这是否意味着停车证可以决定是否允许我们将车停在车库中，我们在车库类中放置的验证方法也可以进入停车通行证类别？不，停车证只能声明允许汽车停放在车库，但此声明只能在车库同意的情况下有效，因此车库类的验证方法属于那里好。
当然，查询关于其条款的停车证仍然是有用的，并且实现这与将验证方法放在车库类中相矛盾，因为这两个构造代表不同的东西，我们只需要要意识到这一点。那么我们如何实施停车通行证呢？条款？同样，这取决于停车道的模型。停车证是否允许访问定义的有限车库？然后，自然解决方案将包含Collection个车库（例如，Set）。但也许停车通行证根据车库的某些财产（例如，其所在地或其所拥有的公司）授予进入车库的权限。然后Collection不代表此停车证的条款。即使您能够收集停车通行证条款适用的所有车库（例如，某个位置内的所有车库，只能是有限的一套），Collection不会代表停车通行证的条款，一旦新车库建成或车库关闭等，这将是相关的。因此在这种情况下，更好的方式来表示停车通行证的条款只是{{1} }。确实，这不允许我们迭代这辆车可能被允许停放的所有车库（记住，最终它是决定的车库，因此这个词＆＃34;可能＆＃34;），但这这不是代码的缺点，它是我们用代码表示的模型所固有的。
我认为停车场模型只是一个简单的例子，在提出这个问题时你想到的问题更复杂，但是，我不认为你问的问题一般可以回答，所以我试图回答停车场模型。