Classes:

Each class in C++ consists of a header
file and an implementation file - class.h and
class.C.  Classes start with a capital letter
(for consistency); the  C++ compiler is case sensitive.
Keep most data private.

Main programs do not have a header file and the
header files of each object referenced from
the main program is included.

Header files:

In a header file, the private and public variables
and methods are declared.  If any code is put in the
header file it should be restricted to one or two
lines NO MORE (could end up with large programs if
more code is put into the header).  Also helps
when inserting the header into the OODB.

Calling methods:

Methods are called via pointers.  For example
method sun_position of a Sun class is called
by declaring a variable of type Sun pointer:

Sun* s

Assuming the sun_position method returns the
following structure

struct SP {
	float alt
	float azi
}

Then to call the method do:

SP pos_now

pos_now = s->sun_position_1()

The method could have been called using a
dot notation:

Sun s
SP pos_now

pos_now = s.sun_position_1()

but this would require that the code for the class
has to available before the method is called - that
is the memory for the object of class Sun would
have to be allocated at compile time and not at
run time.  Therefore avoid using the dot notation
to call methods from objects always use pointers
to the objects.

Access to pointers to other objects:

A method which calls a method in another object 
needs to have access to a pointer to that object.
This can be achieved in several ways.

   By passing a pointer via the parameters of the method:

   A pointer to the object required by the method could
   be sent via its parameters.

   Global pointers :

   Some of the pointers to objects could be defined globally
   such as Sun, Site, Climate, Sky and Clock because there
   will only be one object of these types.  The pointer would
   be defined globally in the main programm and in the class
   header files as external i.e.

   Sun* sun;   // In the main program

   extern Sun* sun  // In the header files

   This means the name of the sun object has to be predefined.

   Using constructors:

   When a variable of type class is declared its 
   appropriate constructor can be called.  e.g.

   sky = new Sky(argument list);

   where one of the arguments could be a pointer to a sun object
   which has already been created in the main program.

   The constructors have the same name has
   the class.  There may be more than one constructor - they
   can be differentiated by the number and type of parameters.
   The sky object will contain a pointer to a sun
   object in its private data and this has been provided via
   its constructor.  Therefore when methods within the sky
   object are called there is no need to send a pointer via
   the method parameters because the necessary pointer was
   supplied when the sky object was created.

   If the model builder wished to change the type of sun
   a method within the sky object is required which
   can change its private sun pointer.  This could be
   achieved by having a list of sun users.  If the model
   builder wished to change the type of sun and each 
   object has its own pointer to the sun in its private data
   a pointer to each object is put in a list sunuser.
   Therefore when using the constructor to define objects
   which the object accesses a change facility may be required.

Using two sun position methods:

Suppose there are two methods within the Sun
class called sun_position_1() and
sun_position_2().  A programmer developing a Sky
solar() method may wish to allow a model builder
to flexibly call either sun position method.
This can be achieved two ways:

   Using a switch:

   The programmer could choose the sun position method to be used 
   by receiving an integer via the parameters of the Sky solar()
   method    specifying the method to be chosen.
   The programmer would be required to know in advance
   the number and names of the sun position methods in
   order to make the switch.  Sun and Sky class would consist of:

   class Sun{ // In Sun.h
   public:
     SP sun_position_1();
     SP sun_position_2();
   }


   Sky::solar(int num) // In Sky.C
   {
   switch (int) {
   case 1 : s->sun_position_1();
   case 2 : s->sun_position_2();
   }
   }

   Using derived classes:

   The methods sun_position_1 and sun_position_2 in Sun
   class are changed to derived classes of Sun.
   Therefore in Sun class, instead of
   two sun position methods there would be one virtual
   method and this method is redefined in the 
   derived classes i.e.

   
   class Sun{ // In file sun.h

   public
     virtual SP sun_position()
   }


   #include sun.h // derived class in file sun1.h

   class Sun1 : Sun {

   public
     SP sun_position()
   }

   #include sun1.h // implementation of sun1 in file sun1.C

   sun1::sun_position()
   { // calc method 1}

   The above is repeated for calculation method 2
   i.e. create a derived class of Sun called Sun2.
   In the Sky method solar() the following is required:


   #include sky.h // in file sky.C

   Sky::solar()
   {
   SP pos_now
   pos_now = s->sun_position()
   }

   where s has been declared in the method solar:

   Sun* s

   s pointer is passed either via the parameters or
   via the constructor.

   When an object of Sky class is initialised in the
   main program a pointer to the derived class Sun1 or Sun2
   is sent via the parameters of the Sky constructor (see
   section on Initialisation for a discussion of constructors)
   and not a pointer to Sun.  The use of the virtual
   method sun_position() in the Sun class and a redefinition
   of the method in the derived classes allows the appropriate
   derived class to be chosen via the
   main program and not stuck in the code of the class definitions.
   This does mean that we are stuck with the name of the virtual
   method but once that is agreed upon there is no limit to the number
   of derived classes.

Multiple inheritance and alternatives:

In the above example derived classes and a virtual method
was used to deal with the two sun position methods.  Suppose there
are three methods for calculating solar_radiation, sun_radiation_1()
sun_radiation_2() and, sun_radiation_3() 
where the methods call the method sun_position.
There are two ways of dealing with this problem depending on
whether information is shared between the sun position and
sun radiation methods.

   Information is not shared:

   The methods do not belong in the same class then a parent
   class Sun_radiation is defined with Sun_radiation_1 and
   Sun_radiation_2 being derived classes.  Each
   derived class can refer to the Sun (and derived classes)
   using a pointer to Sun.  The model builder then chooses
   the derived classes to be used.

   Information is shared:

   The methods belong in the same class if information is
   shared.  Therefore with 2 sun position methods and 3
   radiation methods there would need to be 6 separate
   derived classes.

Using multiple inheritance:

Multiple inheritance would deal with the above problem.
Using multiple inheritance there would be two classes
Sun_position and Sun_radiation with derived types and
another class Sun would inherit the definitions
of the two classes i.e.

Sun_position		Sun_radiation
derived			  derived              
types	     		   types                
    ________________________
			        
		Sun

Using friend:

The friend construct can be used instead of multiple inheritance.

Parent class		Sun_radiation		Sun_position
Derived classes		Sun_radiation_1	Sun_position_1 - friend Sun
				Sun_radiation_2	Sun_position_2
				Sun_radiation_3	 	 
					 
Class derived from		Sun - friend Sun_position_1
Sun_radiation_1

The complete definition of Sun :

class Sun:Sun_position_n{
  friend Sun_radiation_1
};

The friend constructs would be put in the header files BUT it does
allow the model builder to see the private data and therefore
some validation is lost.

Including header files:

In the .C file include the class header.

In the .h file

   - if using structures defined elsewhere include the 
     respective .h file
   - include the C library
   - include .h files of objects called in the implementation file.

The last two types could be included in the .C file
but for consistency, documentation purposes and for the
use of grep facilities all the header files are include in the
class's interface.  Therefore, the implementation file for the
class only requires to include one file - its own interface.

Compilation:

To compile a class implementation file the following is required :

	CC -c -g <name of implementation file}

where the -c flag means only provide the .o file and not
the executable and the -g flag provides use of the
debugging facility.

Each class implementationare compiled
separately and then they are linked to the main program using :

	CC -g -o sim sun1.o sunrad1.o sim.c

With so many different include files conditional compilation
is required and this is achieved as follows.
A header file starts with #ifndef and ends with
#endif - makes sure that header files are only
defined once during compilation :

#ifndef Top.h
#define Top.h
#include "stdio.h" //system files
#include "bottom.h" 
//other header files are then included
//class definition


//end of file
#endif //end of ifndef

Debugging:

The -g flag used when compiling allows the use of the
debugging facility.  When using the debugger it is useful
to know the methods which are called.  This can be achieved by
putting the following in each header:

// At the top of a header file
#ifndef DEBUG
#define DEBUG //
#endif DEBUG

In the .C file for each method define

DEBUG<<"Name of method("<<variable<<variable<<")|n"

Then when compiling add:

CC -c -g -DDEBUG = cout

Clock and synchronisation:

Many objects may need to be told when their
data is to be updated.  A clock object may
be used for such synchronisation.  Objects which
require to be notified when they should update
their data may contain the following method
to ask the clock object to put it on the update
list :

Sun()
  clock->notifymeonchange(this)

The sun_position method may then be overloaded to
allow its position to calculated at the current time and
at a specified time :

s->sun_position() //at current time
s->sun_position(time) //for a specified time

Radiation between objects:

How should radiation between surfaces be represented and
also which object will initiate the calculations ?
A radiation balance object for each zone and
each type of thermal radiation could be used.  This
radiation object may
contain a list of surfaces which are connected by longwave
radiation, for example.  This object would also deal with the
view factors between the each pair of surfaces.  The radiation object
would initiate the calculation of longwave radiation within the
surfaces and undertake any iteration
required to enable a radiation balance to be achieved.

Use of structures and consistency:

Using sun altitude and azimuth as an example.  If a method
is allowed to get the altitude and azimuth separately from a sun 
object one of the values may have been updated.  Therefore, only allow
methods to get the azimuth and altitude together by calling a sun
position method which returns a record containing two real numbers
whose values are those of sun altitude and azimuth.

Data objects:

How should data which an object requires be accessed ?
One idea is to use a data object which accesses files
and contains the data required for a simulation.  When objects
are initialised using the constructor data is taken from
the data object and sent to the object's constructor in
the main program.
