I'm kind of new to OOP, so I still have quite some doubts when it comes to how different objects should communicate with each other. I have a concrete case in which I can't figure out which is the best design between the two that came to my mind.

Basically, I'm building a web user-interface (HTML+javascript) in which there are three main players:

  • a bunch of Media objects (pics, vids)
  • a MediaManager (a container for the
    medias, loads new medias when needed, etc),
  • and a MediaViewer (a fullscreen stage that shows media in full screen, when they're clicked).

Now, clicking on a Media will trigger its view() method which opens the MediaViewer and sets its content to that of the Media that was clicked.

Once the Viewer is open, the user can further navigate through the medias using the keyboard arrowkeys. The next or previous media to show, when an arrowkey is clicked, is decided by the MediaManager: the manager has a .currentlyViewed property with the current media being viewed, plus it has a list of all the medias, so it knows which media comes next.

My doubt is about the best way to keep this .currentlyViewed property updated.


Pass a reference of the MediaManager instance to each Media object on instantiation, and in their view() method, do something like

mediaManager.currentlyViewed = media.id

This is what I'm doing at the moment, however it seems wrong to me that the media objects need to know what properties their "parent" have and change that object so directly. Is this maintainable in the long run, when I'll need to add other functionalities?


Make Medias "observable" for changes in their view state, i.e. implement a "registerOnViewCallback" method.

Then it's the MediaManager that does something like:

function( mediaId ) { 
    mediaViewer.currenctlyViewed = mediaId; 
} );

now medias no longer need to know what properties the MediaManager has, they'll blindly execute whatever callback was given to them. However, this code is more indirect and may be more verbose.

Which is the best pattern, what problems arise with the other one, and why?

Thank you.

1 Answer 1


Whenever you're designing some classes, just think: "who should be responsible for what"? If you keep things simple and think about what makes sense for certain classes to do or be, then you'll naturally arrive at clean, easy-to-understand, and decoupled designs.

In your particular case, I don't think it makes sense for Media to have "view", which is causing this awkwardness that you're having trouble with. Seems more natural for the viewer to be the one that "shows" (views) a given media item and the manager to be the one that tells it what to show and when (e.g. when the user hits "enter").

Here's how I think of your situation (which is mostly what you've already said):

  • Media has all data about a media item.
  • Viewer has all controls and logic to display a media item. Viewer might use a Media's getters to show specific details about an individual Media.
  • Manager has Media collection; it listens for keyboard/mouse input and selects the appropriate Media item. It uses a Viewer to display the currently selected Media.

These can be directly translated to member fields and functions in each class/object.

Your intuition about Options 1 and 2 is right. Option 1 is unnecessary coupling; Option 2 is unnecessary complexity. Viewer knows how to "view" things and Manager manages everything; Media just holds all the data about an individual item.

Hope this helps, and good luck.

  • Great answer and explanation, I see now where my code could be improved (no view method on Medias). Thanks!
    – Daniel
    Aug 10, 2016 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.