CODEWITHSUNDEEP
couplingoop
poulenc
poulenc

Reputation: 81

Coupling in OO design

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:

  1. 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.
  2. 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....

Upvotes: 3

Views: 242

Answers (4)

Vladimir Ivanov
Vladimir Ivanov

Reputation: 43088

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:

addToMeeting(Identifiable action);

and inside the method do

this.actionId = action.getID();

Upvotes: 1

LBushkin
LBushkin

Reputation: 131676

If the only think you ever plan on linking to Meeting instances are actions, then it would seem most appropriate to make Meeting aware of Action, rather than the other way around.

Having the Actions class manipulate the internals of Meeting breaks encapsulation and generally makes it harder to maintain such code. So, I would expose a method addAction(Action a) on Meeting in 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 Meeting know about Action, or vice verse, you could define an interface such as IMeetingItem which exposes the necessary information that Meeting would need to link to such items. Action would then implement IMeetingItem, making it possible to do something like:

meeting.addItem( action );  // action treated as an IMeetingItem in this context

Note that in both approaches, it is the Meeting class that mediates the functionality of adding an item to itself, rather than having the item being added manipulate the internal representation of a meeting.

Upvotes: 5

Nate
Nate

Reputation: 30636

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.

Upvotes: 0

Cylon Cat
Cylon Cat

Reputation: 7201

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.

Upvotes: 0

Related Questions