Re: SyncronizingProxyFactory: Pattern or antipattern?
On Mar 26, 10:57 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
Daniel Pitts wrote:
I have a class "Game", which contains at least one member of type
"GameState". GameState is an abstract class, implementing the "State/
Strategy" pattern. Certain method calls are only valid with certain
states. The actual value of the GameState object depends on the valid
operations on Game.
OK. That makes sense.
I created a
facade class "GameController" which references a "Game" object. There
can be several GameController objects per Game object. GameController
delegates to a few methods in Game, and then all methods in
game.getGameState().
If GameController is talking directly to the GameState then your design is not,
after all, a variant on the State pattern (or Strategy, come to that), and I no
longer feel I understand what the design is. That's not to suggest that
there's anything wrong with the design, but take my remaining comments with
corresponding caution.
To put it another way. my GameController only exposes methods which
are transactional. It is also only invoked by a user performing an
action in a GUI. The operations themselves are fast enough, and
spread far enough apart, that the synchronization isn't going to harm
performance, and is actually required for proper operation.
It sounds as if you GameController has responsibility for grouping primitive
operations on Game into semantically/transactionally atomic units. If so, then
I question whether it's appropriate to hide that -- critical -- aspect of its
function in the implicit synchronisation provided by a SynchronisingWrapper
/around/ a GameController.
Does this design make more sense? Or do you still think its an
antipattern?
Let me put it this way: I'm /less/ skeptical now ;-)
-- chris
:-)
Okay, let me try to clarify the design further...
The Game object contains a method GameState getState().
GameControllerImpl has a reference to a Game object. each method on
GameController either calls a method on Game, or a method on
game.getState(). Calling, say, game.getState().deal() CAN change the
current GameState object referenced in Game. So, by synchronizing
against the Game object, I protect the game's state, as well as the
game's gameState reference.
The GameController interface is ALSO used as an RMI interface/GUI
facade.
Thats why I say I use the State pattern. The behaviour of the object
returned by game.getState() is likely different every time.