Next page | Contents page |

Design and code in steps

It is impossible to sit down and write all in one go a program of any size other than trivial. A strategy is needed, to build the program in stages.

We start with a list of requirements. In the present case that will mainly be the rules of a game and you can find the rules for Spider solitaire online so I will not repeat them here. (You can play the game in Microsoft's solitaire collection but go offline first unless you want to be swamped by advertisements.)

The requirements normally form the basis of User Acceptance Tests (UAT) which will confirm when the project is complete.

We start with a general idea of the kinds of objects we will need. Apart from the GAME itself we will clearly need objects of type Card from a Deck (or Pack?) arranged on screen in Columns. We will also need some user interaction for moving cards around, for undoing moves, starting new games, and so on. It would be useful to make lists of such things.

For each type of object we need to think about its properties (suit, value for cards) and its possible behaviour (methods), such as shuffle() for a Deck of Cards.

When we start writing lines of code an important technique is

	  write a few lines
	  test them
	until finished

That example is called pseudocode: just outlining what is to be done in English, not in any formal syntax.

The really important thing here is testing. It is no good trying to write pages of program (or even a single full page) and expecting it to work first time. No matter how good you are it will almost certainly fail and you may not be able to see where the problems lie in the large amount of work. Write incremental amounts and keep testing. Any problems will then just be due to the small amount just added.

Another useful part of this technique is writing dummy functions in places where you do not yet know how to do something. An example we will meet soon is shuffling a deck of cards. To start with just write, in the file for type Deck:

	Deck.prototype.shuffle = function ()

Call that where it will be needed, knowing that in a test it will not do anything yet. Then later worry about how to fill in the body of that function, to make it really shuffle the cards.

For those just learning JavaScript: we are defining shuffle() as a method that all objects of type Deck will inherit from the prototype that all objects of this type will derive from. Objects have properties which are usually their own, not inherited from the prototype. But all objects of a given type will use the same methods, so putting them in the prototype avoids repeating them. Properties = data, defining the state of an object. Methods define the object's possible behaviour.

Next page | Contents page |