Tic Tac Toe Design Pattern

Question

Hey everyone,

I was wondering if I could get your thoughts and advice as to what would be the best/most advantageous design pattern for a networked Tic Tac Toe game?

I have been looking at the following design patterns: Factory, Abstract Factory, Singleton, Prototype, and Builder.

In your experience, which would be the best to use, and why?

Right now, my Tic Tac Toe game is a threaded client/server game that can be played over the internet via sockets. However, I am going to refactor the game in some way to make use of a design pattern.

I was thinking about setting up a client/server architecture that can be used for playing many different types of games, such as tic tac toe, connect 5, etc...

What direction should I go? I am looking to go into a direction that will really give me some experience with design patterns...

Thanks!

Answer 1

Different patterns are used for different reasons. More often than not you'll see more than one design pattern used in a single app, it's a case of using the right pattern for the right job.

For instance in one web app I might use the singleton pattern for a settings class and a factory class for database connections. The singleton ensures I only have on settings object and the factory class takes care of handing me a database adapter appropriate to my environment.

Answer 2

The patterns you name are not architectural patterns, but as stretch, the builder pattern is probably a good fit for a multi-game server that uses a generic infrastructure to serve different games. Here your builder would assemble a specific game engine based on (abstract) 'game board', 'game rules', 'game engine', etc.

Answer 3

Since you are looking to set up the architecture for many different games, that's a good place to try your hand at implementing a factory and/or abstract factory pattern. That way, when you ask for a new instance of a game, you can decouple your code from which particular game is being started through requesting a new instance of a game from the factory.

I want to caution you that design patterns don't automatically make your code "better". Don't get me wrong, design patterns are extremely useful for complex systems and creating reusable, extensible code bases (not to mention creating better organization and clarity) but they should only be applied when it makes sense. Trying to apply design patterns everywhere in your code will most likely lead to implementing patterns that don't fit your particular problem or are overkill in terms of complexity.

Writing a factory to generate instances of a hello world string in a hello world application clear is clearly overkill. Writing factories to hand out pre-configured socket connections in a large enterprise client/server architecture is a more natural fit. Your application probably falls somewhere in the middle, and its up to you to figure out whether or not design patterns will be helpful in your specific project.

Answer 4

A design pattern is just a name for a way to design something. A tic-tac-toe game could use all of the design patters, or it could do without them. They're just a pattern on how to do a particular thing.

You want to refactor your code, fair enough, but don't do it because you want more design patterns in it. Do it because you want to clean up your code, make it more general and maybe extend it, to other games.

To get a good answer on which design pattern to use, give a specific example:

Q. How should I limit the network_handler to one instance? - A. Use Singleton

Otherwise you could find a reason to include practically every design pattern.

Answer 5

Caveat: I hate when people use "design patterns" as a GOAL. Design good code and if what you are doing looks like a DP, use the DP to help you improve the code. But don't start out saying "I want to write my program using the Striking Crane Pattern." That's putting the cart before the horse. DPs should emerge from your design. They shouldn't drive the design.

EndCaveat

You are already using design patterns. DPs are just jargon for commonly found "patterns" used in programming. What you should first be asking yourself is "How do I recognize the design patterns in the network game I've written?"

After that you can worry about going forward. To have multiple games you will probably want to use an abstract factory pattern to handle your games. The server calls the factory to get a game object that knows how to play the chosen game.