Graphical crop simulation

The object-oriented section of the course focused on the development of a simple farm simulation. Whilst you did not create a fully working farm, you did create crops and animals which can grow depending on the available light, water and food. In addition, you created a field to which you could add your animals and crops.

You controlled the growth of the crops and animals via a straight-forward command-line menu and likewise you used a menu to add and remove crops and animals from the fields.

However, using a menu for this kind of functionality is pretty clunky, therefore in this section we will develop graphical user-interfaces, first for crops, then for animals and finally for the field.

Code structure

If you are coming from a Visual Basic 6 or Pascal/Delphi 7 background then you are probably used to creating the user interface using a interface builder and then adding the program logic 'behind' the interface components (double-clicking on them). This would mean that the code for the crops, animals and field would probably be part of the main window of your program.

Integrated code

You could say that the program logic (the code that actually gives the simulation functionality) is integrated with the user-interface code. Creating you code in this way may mean that your program logic is dependent on your interface, therefore if you wanted to change how the simulation worked or how the the interface looked you may have to make changes to both the interface code and the simulation code.

The approach we take in this tutorial is different, you have already created classes that have all of the functionality required for this program. We are going to re-use this code and develop a user-interface that can interact with this code but it will remain separate.

This means that if we want to change the interface we can be sure that we will not need to change the underlying simulation code and vice-versa. Reducing the dependency between the sections of code means it would be easier to use the same simulation code in another project with a totally different interface.

Decoupled code

A-Level projects

However, at A-Level there is another reason for ensuring that your students develop their code in this way: avoiding cakes that are all icing.

Many students will spend ages creating pretty interfaces using interface builders and will neglect the underlying functionality. By forcing them to develop classes for functionality first and then making them test these with a command-line interface you can ensure that they will create projects that meet most of their objectives before they even consider creating the graphical user interface.

They have to bake the cake before they ice the cake.