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:
- There开发者_运维百科 is the
Gui
module which imports aChessWidget
module; ChessWidget
just wraps theChessWorld
module and importsCellButton
;- The
CellButton
module imports the moduleCell
; - The
ChessWorld
module importsBoard
(to represent it) andPlayers
(to notify them and fetch their moves); - The
Board
module imports modulePiece
; - The
Piece
module imports modulePlayer
;
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.
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.
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.
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").
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?
精彩评论