正确的面向对象通信建模
在我的编程中不断出现一些东西，那就是两件事从某些角度来看是相同的，但从另一个角度来看却是不同的。 就像，假设您构建了一个由火车连接的火车站图，那么 Vertex 和 RailStation 类有时相同，有时则不同。
所以，想象一下我有一个非常代表火车站和火车的图表。 然后我将此图交给另一个对象，该对象删除一些顶点，然后我希望相应的火车站消失。
我不想让火车站成为顶点的“属性”，它们不是。 另外，问题是对称的：如果我删除火车站，我希望相应的顶点消失。 建模或通信的正确 OO 方式是什么？ 如果最终整体用法简单易行，我愿意通过编写一些支持方法或类来多走一些路。
我目前正在使用 Smalltalk 编程语言，但我认为这个问题并不是专门针对 Smalltalk 的。 我只是提到它，因为在 Smalltalk 中，您可以执行一些很酷的技巧，例如检查调用堆栈，这在这种情况下可能会有所帮助。
更新： 嗯，火车站不是 Vertices！ 他们是吗？
好吧，让我们按照答案的要求考虑真实的代码。 让我为一个有孩子的人建模。 这是最简单的事情，对吧？ 孩子也应该认识他们的父母，所以我们就像一棵双向相连的树。 为了使父母与孩子的分离变得更容易，我将父母和孩子之间的联系建模为关系，并具有父母和孩子的属性。
所以，我可以实现parent>>removeChild：也许像这样
removeChild: aChild
(parent relationshipWith: aChild) disband.
所以，父级有一组关系，而不是子级。 但每种关系都对应一个孩子。 现在我想做这样的事情：
parent children removeAllSuchThat: [:e | e age < 12]
这应该删除和孩子的关系。
在这里，关系和孩子在某种意义上是对应的。 那么，我现在该怎么办？ 不要误会我的意思，我完全意识到我可以在不引入关系类的情况下解决问题。 但事实上，父母和孩子确实共享一种关系，那么为什么不对此进行建模并使用它来帮助不那么迫切地解散双重链接呢？
Something keeps showing up in my programming, and it is that two things are the same from some viewpoint, but different from another. Like, imagine you build a graph of rail stations, connected by trains, then the classes Vertex and RailStation are sometimes the same, other times not.
So, imagine I have a graph that very much represents rail stations and trains. Then I hand this graph to another object, which deletes some vertices, and then I want the corresponding rail stations to be gone.
I don't want to make rail stations "properties" of vertices, they're not. Also, the problem is symmetrical: If I erase a railstation, I want the corresponding vertex to be gone. What is the proper OO way to model or correspondences. I'm willing to go a few extra miles by writing some support methods or classes, if in the end the overall usage is simple and easy.
I'm currently using the Smalltalk programming language, but the question isn't really smalltalk-specific, I think. I just mention it because in Smalltalk, you can do cool tricks like examining the call stack, which might be helpful in this context.
Update:
Well, RailStations aren't Vertices! Are they?
Ok, let us consider real code, as demanded in the answers. Let me model a person with children. That's the easiest thing, right? Children should also know their parents, so we have like a doubly linked tree. To make disbanding parents from children easier, I model the link between parent and child as a Relationship, with properties parent and child.
So, I could implement parent>>removeChild: perhaps like this
removeChild: aChild
(parent relationshipWith: aChild) disband.
So, a parent has a collection of relationships, not of children. But each relationship corresponds to a child. Now I want to do things like this:
parent children removeAllSuchThat: [:e | e age < 12]
which should remove the relationship and the child.
Here, relationships and children correspond in some sense. So, what do I do now? Don't get me wrong, I'm fully aware that I could solve the problem without introducing Relationship classes. But indeed, parents and children actually do share a relationship, so why not model that and use it to help disbanding double links less imperatively?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在您的问题域中，站点不是一种顶点吗？ 在这种情况下，为什么不从 Vertex 派生 Station 呢？
请注意短语“在您的问题域中”的使用。 您的问题似乎与图表中显示的火车站的使用有关。 所以是的，在这个域中，站就是顶点。 如果这是一个不同的问题领域，比如火车站架构的数据库，那么它们很可能不是。 大多数现代语言都支持某种名称空间的概念，以允许您在不同的域中拥有具有相同名称的不同类型的实体。
关于你的父母/孩子问题，你又太笼统了。 如果我正在对数学表达式和子表达式进行建模，如果我删除父表达式，我会想要删除并删除/释放所有子表达式。 OTOH，ff我正在英国人口中建立法律责任关系模型，然后当责任伊希斯解散时（比如因为离婚），我只想删除这种关系，而不是删除/释放孩子，它有自己独立的存在。
In your problem domain, aren't stations a kind of vertex? In which case, why not derive Station from Vertex?
Notice the use of the phrase "in your problem domain". Your problem appears to be about the use as railway stations appearing in a graph. So yes, in that domain, stations are vertexes. If it was a different problem domain, say a database on railway station architecture, they may well not be. Most modern languages support some idea of namespaces to allow you to have different kinds of entity with the same names in different domains.
Regarding your parent/child problem, once again you are being too general. If I were modelling mathematical expressions and sub expressions, if I remove a parent I would want to remove and delete/free all subexpressions. OTOH, ff I were modelling legal responsibility relationships in the UK population, then when a responsibility isis dissolved (say because of a divorce), I only want to remove the relationship, and NOT delete/free the child, which has its own independent existence.
看起来您只是希望 RailStation 从 Vertex 继承（is-a 关系）。 请参阅此关于继承的 smalltalk 教程。 这样，如果您有 RailStations 图表，则用于（一般）处理顶点图表的对象将自然地正确处理事情。
如果这种方法不起作用，请更具体（最好使用真实代码）。
It seems like you just want RailStation to inherit from Vertex (is-a relationship). See this smalltalk tutorial on inheritance. That way, if you have a graph of RailStations, an object used to dealing (generically) with graphs of Vertexes would handle things right naturally.
If this approach won't work, be more specific (preferably with real code).
根据您对问题的描述，您有站与顶点的一一对应关系，删除站应该自动删除相应的顶点（反之亦然）。 您还提到构建“由火车连接的火车站图”，这显然是指以车站为顶点、火车为边的图。
那么，在什么情况下站不是顶点呢？ 如果站除了作为顶点之外不存在，并且如果顶点除了作为站之外也不存在，那么将它们维持为两个不同但链接的实体有什么好处？
据我了解你的情况，station-isa-vertex 和继承是建模的方法。
From your description of the problem, you have a one-to-one correspondence of stations to vertices and deleting a station should automatically delete the corresponding vertex (and vice-versa). You also mentioned building "a graph of rail stations, connected by trains", by which you apparently mean a graph in which stations are vertices and trains are edges.
So, in what way is a station not a vertex? If the station does not exist except as a vertex, and if a vertex does not exist except as a station, then what benefit do you see in maintaining them as two distinct-but-linked entities?
As I understand your situation, station-isa-vertex and inheritance is the way to model that.
拥有一个关系对象是个好主意。
我认为这里适当的问题是“应该如何使用它？”。
可能 Parent 和 Child 类扩展了同一个 Person 超类，因此它们将具有一些共同的属性，例如年龄。
在我的想法中，我可以看到以下内容：父对象和子对象必须相互了解，因此两个类必须保持到相同关系的链接。
Relationship 对象在单个父对象和一定数量的子对象之间保持一对多关系，并且它将保留对每个 Person 对象的引用。
通过这种方式，您可以在“Relationshiphp”对象中实现整个解散逻辑，无论您希望多少复杂，都可以。 您可以查询Relationship对象来了解家庭中哪些成员符合您做某事的要求。 您可以使关系安全地解散（和销毁），因为它会知道所有成员并要求他们中断引用，然后准备好销毁，或者要求某些成员离开家庭，保留关系对象活。
但这还不是全部。 关系实际上应该是一个超类，由 HierarchicalRelationship 和 PeerRelationship（或 FriendRelationship）扩展。
这种专业化使您可以通过父级和子级以完全遍历的方式在其他层次结构之间进行链接。
这背后的真正概念是，您的关系对象是以可扩展和结构化的方式查询和组织整堆 Person 对象（或 Vertex 对象）的关键，因此您最终获得的整个数据域在任何意义上都是可用的。例如，您是否想解散团体或在团体之间走某条路径（或铁路）。
抱歉有大量的隐喻。
Having a Relationship object is a good idea.
I think the appropriate question here is "which use should be made of it?".
Probably Parent and Child classes are extending the same Person superclass, so they'll have some attributes in common, age for example.
In my idea, I can see the following: Parent and Child objects have to know each other, so both classes have to keep a link to the same Relationship.
The Relationship object keeps a one-to-many relation between a single parent and a certain number of children, and it'll keep a reference to each Person object.
This way you can implement the whole disbanding logic within the Relationshp object, more or less sophisticated as you wish. You can query the Relationship object to know which members of the family match your requirements to do something. You can make the relationship to disband (and destroy) safely, as it will know all members and would ask them to break the reference and then it would be ready to destroy, or ask to some member to leave the family, keeping the Relationship object alive.
But that's not all. Relationship should be really a superclass, extended by HierarchicalRelationship and PeerRelationship (or FriendRelationship).
This specialization lets you have Parent(s) and Child(ren) to link between other hierarchies in a completely traversal way.
The true concept behind this is that your Relationship objects are the key to query and organize the whole bunch of Person objects (or Vertex objects) in a scalable and structured way, so the whole data domain you end up with is usable in any sense you like, whether you want to disband groups or walk a certain path (or railroad) between them.
Sorry for the huge amount of metaphores.
查看 Fame，请参阅 http://www.squeaksource.com/Fame.html
我们使用
Collection的专门子类，当您添加或删除元素时，它会更新另一端。 此外，您可以使用编译指示来注释您的类以注释关系。 Fame 框架使用这些编译指示来完成各种美好的事情。Take a look at Fame, see http://www.squeaksource.com/Fame.html
We use a specialized subclass of
Collectionthat updates the opposite end when you add or remove elements. Also, you can annotate your classes with pragmas to annotate relations. These pragmas are used by the Fame framework to do all kind of nice stuff.