# Examples 6.2:
Implementation classes

The definition of an implementation class fundamentally differs from abstract ones because implementations have to provided. The various kinds of feature available are discussed and are given examples in Section 6-6 which will not be pre-empted here!

### The palette example

The last example in the abstract classes was about a palette abstraction. Without filling in lots of code details, that example can be used to illustrate the various forms of implementation class which could be derived from that example.

immutable class RGB16 < $RGB_COL is
...
end

together with similar classes, say RGB24 and CMYK32 (the latter sub-typing from $CMYK_COL), could be specified to provide appropriate methods for such colour models. It would then be possible to define palette implementation classes as, say,

class PRINT_PALETTE{CMYK32} < $PALETTE{CMYK32} is
...
end

which is a palette as a reference class model of CMYK ink colours for use in printing something.

### Immutable vis-a-vis reference

The idea of an immutable class is one which has immutable semantics and occupies a relatively small amount of storage so instantiations can be manipulated as values, each manipulation forming a new value object.

The idea of a reference object is one which occupies significant storage the direct manipulation of which would have severe time penalties for execution. Such objects are generally expected to be fairly long-lived - beyond the scope of some current method execution. Pragmatically they are most likely to be placed in dynamic heap storage by an implementation. The main disadvantage of these is that unless special care is taken aliassing will very probably occur.

It is perfectly possible to provide immutable semantics for a reference object (as is expected for implementations of the Required Library class STR). Provided some care is taken, then, reference classes are generally to be preferred over immutable classes for objects exceeding a few components - say three or four.

The use of immutable classes for the actual colour classes - even the four component CMYK model - was, in the light of this, a reasonable decision. Using the same argument it is fairly likely that a palette will have certainly tens if not hundreds of colours and will be long-lived - after all a palette is generally a form of look-up table which is going to be in use for quite some time, once the table has been filled in - thus making that a reference class also seems to be reasonable.

There is, however, no hard and fast rule which will always produce the optimum in terms of speed and space. There are some classes in the required library which could have been put into the other form of class with very little real effect either way. Individual programmers will decide which to use in the light of experience (mainly by making the wrong decision and finding out the consequences!).

### External classes

There is only one rule for external classes and that is that if you are using external resources then there is a need to conform to the external model insofar as is possible. If you are providing external services then you have got rather more freedom - but you will almost certainly find that interfacing with other programming languages means conformance to a common interface specification - often that specified by an operating system.

Before defining new external classes for some task, it is advisable to look at those which the implementers of the Required Library have found to work correctly. This is, of course, implementation-dependent - as will be any external classes which you, as using programmer, may subsequently define.

| Specification Index |  | Language Index |  | Implementation Classes |  | Section 6 Index

Comments or enquiries should be made to Keith Hopper . Page last modified: Monday, 22 May 2000. |