Client Code Refactoring for Test Environment Functionality

[lirmont]

There is a lot of client-side functionality that is written in terms of responding to the PyDatagram objects that are sent back and forth between the client and the server. For instance, at the time of writing this, the code for displaying a map basically requires a very specific PyDatagram object. In contrast, it should generally accept any PyDatagram that contains a map, and it should only have access to the parts required to show a map. By refactoring this client-side code, proper tests can be set up (for instance, displaying a map so that an event can be tested). In short, this refactoring should take code as far out of the "Client" class as possible (so that it can be used among other aspects of the client-side code).

Example operations include removing code from the "Client" into a class that reflects the subject matter of the code. Following that, you'd have the client import this new class as a module, putting a link to the function that you refactored where you removed the code at.

[kivutar]

I totally agree. The client is too monolithic and need to be splited into modules with loose coupling. http://en.wikipedia.org/wiki/Law_of_Demeter .

[CoderBrandon]

I was going to mention this as well and it would help with things going forward to abstract as much as possible in the main.py into their own classes/modules (whatever you would call them in python).

[kivutar]

I began to move graphical related functions to a separate module. I'd like to move things out of the client class first. Moving things into thematic classes in a later time.