Solution getting too big to handle

[Gaz]

I'm trying to write this client/server card room. I've been working on
it all on my tod in my bedsit using VS C# Express 2008. The solution has
grown to include multiple libraries and projects.

It uses the command pattern. A client sends the server commands like
"TABLE#3 SITDOWN" and the server responds to clients with 'Event
Commands' like "TABLE#3 SATDOWN BRIAN".

But with multiple libraries, clients and server, multithreading, GUIs,
it's difficult to expand the solution and test everything because
everything has to be implemented for the whole beast to work.

It's getting a bit too much for my brwain. Am I taking on too much?

 

[Lasse Vågsæther Karlsen]

I'm trying to write this client/server card room. I've been working on
it all on my tod in my bedsit using VS C# Express 2008. The solution has
grown to include multiple libraries and projects.

It uses the command pattern. A client sends the server commands like
"TABLE#3 SITDOWN" and the server responds to clients with 'Event
Commands' like "TABLE#3 SATDOWN BRIAN".

But with multiple libraries, clients and server, multithreading, GUIs,
it's difficult to expand the solution and test everything because
everything has to be implemented for the whole beast to work.

It's getting a bit too much for my brwain. Am I taking on too much?

Not knowing more about your solution you should try to split up the
project into manageable and testable chunks, small enough that you can
understand how one chunk works without having to know about all the others.

For instance, you probably don't need the whole multithreading and gui
part to just test some inner engine that reacts to commands, you can
probably create a command line app for that, or perhaps just some unit
tests.

But then you're a bit thin on details.

 

[Gaz]

Not knowing more about your solution you should try to split up the
project into manageable and testable chunks, small enough that you can
understand how one chunk works without having to know about all the others.

For instance, you probably don't need the whole multithreading and gui
part to just test some inner engine that reacts to commands, you can
probably create a command line app for that, or perhaps just some unit
tests.

But then you're a bit thin on details.

Thank you, yes that's the stage I am at at the moment. It's basically
exactly as you say. Testing the card table engine class and trying to
keep it expandable so I can implement things like timeouts and bots.
Other problems like disconnections during play I have to look forward too.

I'm also finding if I leave my code for more than about a week, then on
return I have relearn how it all fits together. I'm currently commenting
the classes with /// summary blocks.

Sorry for not posting full details, I have an idea /what/ to do, it's
just a question of not getting bogged down by it.

I have a few namespaces:

WorkerLib
Contains the Invoker for the command pattern and a client class from
which a class must be derived (TableClient). Commands are queued and
events are read via this class.

GameLibrary
Includes a Table Manager, Table engine, Player classes, Command handler,
TableClient class that relays events and commands to and from the Tables.

SharedLib
Classes that are used by both server and client, mainly serializable data.

Test
Used for testing.

The GUI and server/client socket and connection stuff is kept out of the
way for the time being.