So I'm working on this game where I have a nested class which has to get access to the member functions and variables of the outer class in order to perform it's functionalities. In particular the outer class contains member functions and data related to game objects whereas the nested class extends an AnimationTimer which basically has to make use of the game objects position in order to draw them on the canvas. Also the outer class has to call the start() method on the AnimationTimer so there will definitely be a need for an instance of AnimationTimer in the outer class. Now since I'm a bit new to this, I'm kinda confused from this post so

  1. Is this really the case of a tight data coupling ?
  2. What do you suggest in this scenario, should I convert it into a non-nested class and access the "parents" member functions through the static modifier (in which case why would this be proper and why not) ?

Any suggestion is welcomed :)

  • 2
    Is the nested class, private? If so, it's an implementation detail and so its an example of cohesion; not coupling. If it's not private, then it most certainly is tightly coupled.
    – David Arno
    Dec 15 '17 at 12:20
  • yes it's not private indeed.. (y)
    – johndoe123
    Dec 18 '17 at 1:29

Tight data coupling is not an anti-pattern; it is a feature. You use tight data coupling when you need the benefits it provides.

The reason you're wondering about this is that you hear a lot about making your classes loosely-coupled these days. Loose coupling exists to allow modularity. You make your classes or modules loosely coupled when you want a clean separation of responsibilities and the ability to swap out modules for something else. Loose coupling makes it possible to do this without breaking things.

But in a game, you may have several classes that must be closely coordinated, and you don't necessarily care about the benefits that loose coupling provides. In this context, loose coupling might actually be a detriment; it adds complexity for no significant benefit, and can have a negative impact on performance.

This is why UI frameworks use inheritance rather than composition (in contrast to what you've been taught about favoring composition over inheritance), because it is more suited to the hierarchies of classes that UI requires. Assembly references in languages like C# and Java are about as tightly coupled as you can get.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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