Refactoring the client

So today I set out to refactor my code. Nothing in terms of what data is sent to the server is changed, neither is how the client looks when run. Basically I wanted to follow some rules I usually set up for myself as I've programmed over the years. Here are some of those rules I had to make my code conform to:

1. Don't Repeat Yourself (DRY)
2. An object should know how to write itself, not another object
3. Do everything with consistency

Now, you might either think these things are either trivial or a no-brainer, but you would be surprised how many people don't follow them and thus make theirs and other peoples' lives miserable. Some of you may already be griping about my code, I know I was. Here is the reason I follow these rules.

Don't Repeat Yourself - This is at the core of my code. I never want to see the same code copy/pasted anywhere in a project. It takes one person not knowing which version needs to be updated to break the entire project or put a bug in because it works through one path and not through another. DRY makes you have one function, one class, one property, period. That way when someone makes a change it works for all or for none.

An object should know how to write itself, not another object - Some people think if they are serializing an object, they should make some kind of class that reads the data out of the object, packages it up, and passes it along. This is just plain wrong. I don't want to know what name or subset of code to look under when I'm trying to get an object to send to someone else. In Java and C# this is much easier because they have serializers that attach to an object as an interface or abstract class and the class keeps this data. We aren't in my code and I had a most of my messages being built by hand in the call immediately before the send which means I'd copy/paste it if i needed the message somewhere else, violating my DRY principle. So I went in and make classes for each of my outgoing messages. They all come from the ISendableObject so that I can consistently encrypt them or send the same message the same way every time.

Do everything with consistency - This kinda follows along with the other 2. In my code, I had places that would use a handler and 1 place where I was going to the object to handle a message instead of through a handler first. So I had to go fix this.

You will see several changes now if you look through the AegisBorn3d project.

I created some new interfaces - ISendableObject and IReceivableObject. These interfaces set up how I send and receive objects.

I created several new messages. Messages are objects that have no real object model to base themselves off of. This includes things like the character creation message and the request to get the list of characters. You will find these in the _Messages directory.

Lastly I created 2 new models under _Models/Cryptography. These models are the ServerPublicKey and the ClientPublicKey. The Client public key is only sent to the server and allows the server to encrypt data to the client, It used to be part of the encryption provider, but I moved it to its own model to follow the second and third rules above.

All these changes together make it easy to create new messages, objects, handlers, and scenes. If I were to take out the handlers, scenes, and messages, it would be a very simple network layer on top of unity to allow encrypted/unencrypted network messaging with smartfoxserver as a small unity package. Next time I will be focusing on cleaning up the server code and making it more object oriented and following the same rules.