OO设计中的耦合
我有两个对象。一个会议对象和一个操作对象（会议中提出的操作）。行动也可以独立于会议而存在。我有两种方法将提出的行动与会议联系起来：
- 有一种关于会议的方法，我可以在其中使用 传入 Action 对象，例如 “addToMeeting（操作操作）”。 在会议的内部 然后我将操作链接到 会议。对于这种方法，虽然 会议对象需要了解的 并使用 Action 上的方法 对象因此变得耦合。
- 有一个我刚刚通过的会议方法 要链接的操作编号，例如 如“addToMeeting(int actionID)”。 现在很好 会议对象没有 需要了解有关 Action 的任何信息 但是......现在代码添加了 会议行动需要知道 如何获取action ID所以有 从此转向 “会议.addToMeeting（操作）”到 这 “会议.addToMeeting（action.getID（））”。
对于良好的 OO 设计，应该使用哪种方法？或者还有第三条路吗......
I have two objects. A Meeting object and an Action object (action raised in a meeting). An Action can also exist independent of a Meeting. I have two ways of linking the Action raised to the Meeting:
- have a method on Meeting where I
pass in the Action object such as
"addToMeeting(Action action)".
WIthin the internals of Meeting
I then link the action to the
meeting. For this approach though the
Meeting object needs to know about
and use the methods on the Action
object so becomes coupled. - have a method on Meeting where I just pass
the action number to be linked such
as "addToMeeting(int actionID)".
Great now Meeting object does not
need to know anything about Action
but......now the code adding the
action to the meeting needs to know
how to get the action ID so has
turned from this
"meeting.addToMeeting(action)" to
this
"meeting.addToMeeting(action.getID())".
For good OO design, which approach should be used? Or is there a third way....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您计划链接到
Meeting实例的唯一想法是操作，那么让Meeting了解Action似乎是最合适的>，而不是相反。让
Actions类操作Meeting的内部结构会破坏封装性，并且通常会使维护此类代码变得更加困难。因此，在这种情况下，我将在Meeting上公开一个方法addAction(Action a)。但是，如果还有其他内容可以链接到会议，您可能需要考虑抽象“会议项目”的概念。
而不是让
Meeting了解 < code>Action，反之亦然，您可以定义一个接口，例如IMeetingItem，它公开Meeting链接到此类项目所需的必要信息。然后，Action将实现IMeetingItem，从而可以执行以下操作：请注意，在这两种方法中，都是由
Meeting类来调节功能将项目添加到其自身，而不是让添加的项目操纵会议的内部表示。If the only think you ever plan on linking to
Meetinginstances are actions, then it would seem most appropriate to makeMeetingaware ofAction, rather than the other way around.Having the
Actionsclass manipulate the internals ofMeetingbreaks encapsulation and generally makes it harder to maintain such code. So, I would expose a methodaddAction(Action a)onMeetingin this case.However, if there are other things that can be linked to a meeting, you may want to consider abstracting the concept of "meeting items".
Rather than have
Meetingknow aboutAction, or vice verse, you could define an interface such asIMeetingItemwhich exposes the necessary information thatMeetingwould need to link to such items.Actionwould then implementIMeetingItem, making it possible to do something like:Note that in both approaches, it is the
Meetingclass that mediates the functionality of adding an item to itself, rather than having the item being added manipulate the internal representation of a meeting.我建议您创建一个接口“可识别”，其上的方法 getID() 由 Action 实现
然后您可以执行以下操作：
并在方法内部执行
I would suggest that you create an interface "Identifiable" with the method getID() on it which is implemented by Action
Then you can do the following:
and inside the method do
只要会议以任何方式与操作相关联，就会产生一定的耦合。但是，您可能会考虑第三种方法，即构建一个生成操作对象的“操作工厂”。一旦创建（并且可能保存），ID 将是 Action 对象的一个属性。该会议要做的就是告诉工厂生成一个操作，并能够访问该操作的 ID 属性。
As long as meetings are associated with actions in any way, you'll have some coupling. However, you might consider a third approach, to build an "action factory" that generates action objects. ID would be a property on the Action object, once it's created (and maybe saved). All that meeting would do is tell the factory to generate an action, and be able to access the action's ID property.
我会选择#1——在你的情况下，耦合并不是一件坏事，因为对象之间有明确的关系。我会选择选项#1。这使您可以选择让会议拥有
MeetingActions[]属性或类似属性。I would go with option #1 -- coupling is not a bad thing, in your case, since there is a clear relation between objects. I would go with option #1. This gives you the option for a meeting to have a property of
MeetingActions[]or something similar.