On Sep 25, 2013, at 11:05 PM, Daniel Sank <sank.dan...@gmail.com> wrote:
> This isn't THAT bad. The client's requestMove is thin and unecessary (I put
> it there for illustration). Still I need to have two separate classes with
> corresponding methods to handle moving the piece.
That's OK. Don't try to reduce your number of classes just for the sake of
having fewer classes. Each class should have a clearly defined responsibility.
In this case, your responsibilities correspond directly to the things that
have to happen on the server (validating the move) and the things that have to
happen on the client (updating the graphical representation to correspond to
the new game state). Having more, smaller classes means that it's easier for
you to understand each class on its own, and programming is nothing if not the
act of promoting local understanding :).
If anything, you should have an additional class to separate out your remote_*
responders and the actual internal state.
> This seems like the kind of thing I could twisted.pb to solve more cleanly if
> I only would look in the right place.
I don't know if this is going to directly address any of your concerns, but
have you considered using twisted.spread.flavors.Cacheable? That will
atomically combine the propagation of initial state with the provision of the
back-propagation channel for updates to that state. It's designed for exactly
what you're doing, maintaining parallel simulated states on client and server.
Does that help at all?
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
