CODEWITHSUNDEEP
oopdesign-patternscircular-dependency
zaphnat
zaphnat

Reputation: 287

how to avoid circular dependencies here

Is there a way to avoid circular dependencies, other than mixing modules, in a arrangement like this(it is a chess application)

Long description:

AND HERE IS THE PROBLEM:

The Player module needs to know about other players and the board, thus importing ChessWorld!

Short description:

The World module needs to know about the Player module (even indirectly by Board/Piece) and Player need to know about World.

Help is very appreciated.

PS: Is not because I cant use circular dependencies, but because they are evil.

Upvotes: 19

Views: 24970

Answers (4)

Alex Martelli
Alex Martelli

Reputation: 881705

Follow the Dependency inversion principle: introduce an interface, which ChessWorld implements, and on which Player depends -- and/or one which Player implements and on which Piece depends (either or both may be appropriate depending on details on the nature of the dependency). This often goes together with Dependency Injection, and, if the dependant needs to dynamically instantiate a number of instance of the dependees, with Factory DPs.

Upvotes: 18

Cohen
Cohen

Reputation: 2720

I think the smell of a circular dependency shows more an architectural/design issue, that shouldn't be solved by DI, late bounding, loose coupling, or any other form of an extra abstraction layer. Although they are all very good mechanisms, but don't solve the problem underneath.

Short: I think the ChessWorld holds too many responsibilities. If you split them up you'll probably will find that the dependencies are responsibilities better suited in a separate module.

Long explanation: I'll try to give an example of how I would refactor it, although it's hard because I don't really now the full problem domain.

NOTE: I am not familiar with Java so I may misunderstand the implications of import and wrap.

But as I understand the dependencies look somewhat like this:

Gui <- ChessWidget <- ChessWorld <- CellButton <- Cell
                                 <- Board <- Piece <- Player
                                 <- Players <- ChessWorld

IMHO the problem is that ChessWorld holds too many different responsibilities. Maintaining the list of players is probably better in a separate module like PlayerList, RegisteredUsers or OnlineUsers or something similar. After that refactoring your depedencies would change as follows:

 Gui <- ChessWidget <- ChessWorld <- CellButton <- Cell
                                  <- Board <- Piece <- Player
                                  <- Playerlist <- Player

PlayerList is probably something you would have in the player module. Now Chessworld depends on the player module and not in the other direction.

I am not sure if it fits your intention perfectly, but I am very interested in discussing this, so please comment.

Upvotes: 8

kyoryu
kyoryu

Reputation: 13055

Consider what each object really needs, and not what it just happens to need at the moment.

A Piece probably doesn't need to know about a Player - what it needs to know about is something that it can send updates to.

So, for that example, create an interface representing a "PieceMessageListener" or some such, and have the Player implement that. Now, both concretions are depending upon an abstraction (going to the rule of "concretions should depend upon abstractions, abstractions should not depend upon concretions").

Upvotes: 3

slugster
slugster

Reputation: 49984

I'm gonna stick my hand up here and say... IMHO you may have over-designed this.

Why does a piece need to have knowledge of the player? A piece in chess is either black or white, irrespective of who is controlling (playing) it.

You mention "player module" and "piece module" - why are they separate modules? Why aren't they just data classes (domain objects) together in the same module?

If i have over analyzed this or failed to understand how you have constructed your game then by all means ignore what i said. OTOH maybe i did read things right?

Upvotes: 0

Related Questions