Move towards a cohesive design principle

[ttsherpa]

Restructure the code to more of a "Factory Design" possibly "Abstract Factory Design style of code. Because there is so much clutter and each class heavily depends on other classes. This is the main reason why large portions of chatting fails, functions becoming extremely long and become repetitive "public" work, there was no specific design pattern we noticed to allow future legacy code writers to add on to the existing code. For example, why does Hand.java hold all of the cards "live" in the game both on the table, it just doesn't make sense. Also, why does Hand.java calculate who one the game, it doesn't make sense too. Most importantly, why is every method that should not be accessed in other functions "public" instead of "private." Everything is just unorganized in structure and definition!

Estimate =

400 ~ single player completely works after restructuring
400 ~ multiplayer completely works after restructuring
200 ~ chat completely works after restructuring

[jalexanderqed]

I am not convinced that M16 implemented a "factory design," but they significantly improved the code quality and readability. Some form of MVC architecture would make sense in this context (note that this is compatible with the factory design), and the beginnings of this are already present in the code, so making the code conform to this should not be too difficult. Part of your work on this issue should include an examination of the existing code and proposal of how it could be improved structurally.

[jalexanderqed]

F16 OK (200 pts)

[sean-shelton]

F17 OK (200 points)

[Sierrasch]

This was mostly done in W18. At this point I think the code is in a pretty organized and good place so I am closing this issue for now.