How do I turn this structure into a good OO design?

Question

0.00/5 (No votes)

See more:

Hi all,

I create small games in WinForms, Silverlight etc using C#. I have a question regarding the correct OO way of buiding the structure of classes.

This is a typical structure for me:

Soldier.cs
SoldierCollection.cs (an array of Soldiers plus methods that take care of manipulations of this array)
Board.cs (the GUI component, such as "Form1" in WinForms. Here I fill pictureboxes with data (ie Soldiers) from the SoldierCollection.
Rules.cs (Rules for checking for allowed movements etc)

What happens now is this:
1. First, Board.cs creates an instance of Soldiercollection.cs.

2. Next, it calls a method in this instance of SoldierCollection.cs, which in turn creates an array of Soldiers.

3. After this has been done, Board.cs gets graphically filled, using data from the instance of SoldierCollection.cs.

4. When a soldierpiece (say a picturebox) is dragged over the board using the mouse, another method in Soldiercollection.cs is called, which in turn calls the appropriate method(s) in Rules.cs. The result is then sent back to SoldierCollection, which decides what happens, and the result is returned to Board.cs, to update the playing field or perhaps showing a win.

The question is how all of these should connect to each other as OO-nicely as possible.

For example, both Rules.cs and SoldierCollection.cs will only appear once (as opposed to Soldier.cs, which may have dozens of instances). Therefore, I am tempted to set these to static. However, I have a feeling that this is looked down upon from an OO viewpoint.

So my specific question is: Is my design and process described above suitable or should it better be done in another way? And should I have the SoldierCollection or Rules classes static? What would be the pros and cons of using static classes here? (I also guess that if I want to track wins or keep playerturns, this must either be done in Board.cs or I would need yet another class, such as Game.cs. Perhaps I should start out with a Game.cs class that in turn connects to SOldierCollection etc and then flushes out the data to Board.cs for display?)

Thanks!

Petter

Posted 21-Nov-14 4:05am

petter2012

Add a Solution

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sinisa Hajnal · Accepted Answer · 2014-11-21T04:16:00

Solution 1

I'd have one Game class with general settings, context and such which would show Board, Options, Highscores, whatever.

You have Board which is just "stupid" View, it doesn't do anything but show data.
SoldierManager which handles the soldiers - terrain results, rule invocation etc...

SoldierCollection which takes care of soldiers (only having collection methods such as add, remove, get, getAt etc...)

Base (or even abstract) Soldier class holding generic data (hitpoints, strength, armor, whatever)

Inherited classes from Soldiers - Heavy infantry, Cavalry etc...

Each soldier should know how much it can move and how much movement remains to him, how hurt it is etc...he should know where he is and similar data (this "moveable" data could be separate class that soldier updates)

This is not really something that can be quickly discussed. Don't make the classes static unless you have to. Keep their instances in Game (main) class and work from there.

Posted 21-Nov-14 4:16am

Sinisa Hajnal

Comments

petter2012 21-Nov-14 10:37am

Thank you so much for your quick and very precise reply. Actually I already have Soldier as an abstract class, so I did something right at least. :) I find that I was also right in my assuption of the need of a Game class to differ between the game and the UI.

I still wonder though what is conceptually wrong with static classes. For example, I took a look at static classes at MSDN. They showed a temperature converter, with a static class with methods for the Fahrenheit/Celsius conversions. Just as in their case, almost all classes in my example appear only once and the Rules (I guess that's SoldierManager in your vocabulary) is not that different from the temperature conversion methods. I don't question you, I'd just like to learn the idea behind this.

Sinisa Hajnal 24-Nov-14 3:48am

Nothing wrong programmatically, really, it is just that there is no need for it logically. Your game is conrete instance of the game with its own rules and soldiers...static instance represents a class data that is not bound to any specific instance.

Example of "correct" usage is System.Math.Abs - you use Abs method without doing Math m = new Math :) There is no need for it. But your game has its own specific collection of soldiers, not "shared" one.

petter2012 24-Nov-14 5:51am

Thanks! Yes, I understand it could be written one way or the other without problems. I thought that perhaps static classes would have better performance, but in WinForms - who cares. :)

How do I turn this structure into a good OO design?

1 solution

Solution 1

Add your solution here

Preview 0

How do I turn this structure into a good OO design?

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us