; Do we need full object-oriented features
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Do we need full object-oriented features

VIEWS: 15 PAGES: 37

Do we need full object-oriented features

More Info
  • pg 1
									         Do we need full object-oriented features?


                                Mike Fisher


                                    ECMWF



                          18 November 2009




Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   1 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   2 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   3 / 37
Definition of “Object-Oriented”
Object-oriented programming deals with objects.

An object is a combination of data, and functions that act on that data.

In general, an object restricts access to its data. Its functions provide an
interface to other objects.

The functions are regarded as being part of the object, and are carried
round with it.

Object-oriented languages regard programs as collections of interacting
objects.

In contrast, procedural languages (such as Fortran 90/95) regard data and
functions (subroutines) as distinct. The emphasis is on the functions
rather than on the data. Functions are global entities, accessible from
anywhere, and not attached to particular data structures
    Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   4 / 37
Definition of “Object-Oriented”

The primary mechanism used by object-oriented languages to define and
manipulate objects is the class

Classes define the properties of objects, including:

     The structure of their contents,
     The visibility of these contents from outside the object,
     The interface between the object and the outside world,
     What happens when objects are created and destroyed.

There is no direct equivalent of the class in Fortran 90/95, although
several properties of classes can be simulated using modules.



    Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   5 / 37
Definition of “Object-Oriented”


Different definitions of “object oriented” stress different aspects. But most
agree that the following concepts are important:

     Encapsulation
     Inheritance
     Polymorphism
     Abstraction

The rest of this talk will consider each of these concepts in turn.

Let’s start by considering encapsulation. . .




    Mike Fisher (ECMWF)    Do we need full object-oriented features?   18 November 2009   6 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   7 / 37
Encapsulation
In c++:
c l a s s Animal {
private :
    d o u b l e h e a l t h =50 , h a p p i n e s s =50 , h u n g e r =50;
public :
    v o i d e a t ( ) { h u n g e r =0.5∗ h u n g e r ; }
    v o i d p l a y ( ) { h a p p i n e s s =50+0.5∗ h a p p i n e s s ; }
    v i r t u a l v o i d makeNoise ( ) {
        c o u t << ” w o o f o i n k ” << e n d l ;
    }
};


With this definition, we can make and manipulate objects of class Animal:
Animal l a s s i e , babe ;
l a s s i e . eat ( ) ;
babe . p l a y ( ) ;
l a s s i e . makeNoise ( ) ;

    Mike Fisher (ECMWF)         Do we need full object-oriented features?    18 November 2009   8 / 37
Encapsulation

Note how the class defines:

     the contents of Animal objects: health, happiness, etc.,
     the visibility of the contents: private,
     the interface by which the contents are accessed: eat, play, etc.

Note also that the important information describing an Animal is
contained within and manipulated by the Animal. It is not held in some
separate common block. It is not initialised in a separate set-up routine.

This is encapsulation.

We can do much the same using modules in Fortran 90/95:



    Mike Fisher (ECMWF)    Do we need full object-oriented features?   18 November 2009   9 / 37
module A n i m a l m o d u l e
  type : : Animal type
      private
      r e a l : : h e a l t h =50 , h a p p i n e s s =50 , h u n g e r =50
  end t y p e A n i m a l t y p e
contains
  subroutine eat ( t h i s )
      type ( Animal type ) : : t h i s
      t h i s%h u n g e r = 0 . 5 ∗ t h i s%h u n g e r
  end s u b r o u t i n e e a t
  subroutine play ( this )
      type ( Animal type ) : : t h i s
      t h i s%h a p p i n e s s =50+0.5∗ t h i s%h a p p i n e s s
  end s u b r o u t i n e p l a y
  s u b r o u t i n e makeNoise ( t h i s )
      type ( Animal type ) : : t h i s
      p r i n t ∗ , ’ woofoink ! ’
  end s u b r o u t i n e makeNoise
end module A n i m a l m o d u l e


    Mike Fisher (ECMWF)        Do we need full object-oriented features?   18 November 2009   10 / 37
Encapsulation




To make and manipulate Animal objects:
use Animal module
t y p e ( A n i m a l t y p e ) : : l a s s i e , babe
c a l l eat ( l a s s i e )
c a l l p l a y ( babe )
c a l l makeNoise ( l a s s i e )




    Mike Fisher (ECMWF)        Do we need full object-oriented features?   18 November 2009   11 / 37
Encapsulation



Note the differences between the c++ and the Fortran versions:

    Fortran is much more verbose (19 lines of code versus 10)
    c++ provides a more natural and concise syntax.
    In c++, the functions eat, play, etc. are considered as part of the
    object.
    In Fortran, eat, play, etc. are just globally-available functions that
    take an argument of type Animal type.




   Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   12 / 37
Encapsulation
A more concrete example of this type of encapsulation is the
distributed vector type that was introduced into the IFS in CY18R2.
(Eventually superseded by the control vector type).

Distributed vectors provided a 1-dimensional vector that hid their
internal structure (in particular, the fact that the elements are distributed
over processors), and provided a clean interface to the rest of the code:

A particular feature of distributed vectors was their use of operator
overloading. This allows us to write
 x = d1 + d2


instead of
 c a l l a d d d i s t r i b u t e d v e c t o r s ( x , d1 , d2 )


    Mike Fisher (ECMWF)          Do we need full object-oriented features?   18 November 2009   13 / 37
Encapsulation
Distributed vector Example:
use d i s t r i b u t e d v e c t o r s
t y p e ( d i s t r i b u t e d v e c t o r ) : : d1 , d2
r e a l : : x (10000) , y (10000)

c a l l a l l o c a t e v e c t o r ( d1 , 1 0 0 0 0 )
c a l l a l l o c a t e v e c t o r ( d2 , 1 0 0 0 0 )

d1 = x        ! D i s t r i b u t e t h e e l e m e n t s o f x among p r o c e s s o r s .

d2 = 5 . 0 ∗ d1 − 3 . 0 ∗ d2                        !   The c a l c u l a t i o n s h e r e a r e
d1 = d2 / d o t p r o d u c t ( d1 , d2 )           !   p a r a l l e l i s e d , and t h e d o t
                                                    !   p r o d u c t i n v o l v e s message
                                                    !   passing .

y = d1        ! T h i s s t a t e m e n t d o e s message p a s s i n g t o g a t h e r
              ! t h e d i s t r i b u t e d e l e m e n t s o n t o one p r o c e s s o r .

    Mike Fisher (ECMWF)          Do we need full object-oriented features?    18 November 2009   14 / 37
Encapsulation: Summary



    Although a full object-oriented language provides a more natural
    framework, simple objects and encapsulation are perfectly possible in
    Fortran, through proper use of modules.
    Several examples have made their way into the IFS in recent years
    through the increasing use of derived types:
          GFL structures, Control vectors, Distributed vectors, Spectral fields,
          etc.
    However, most modules in the IFS are glorified common blocks, with
    globally visible contents and no attempt at encapsulation.




   Mike Fisher (ECMWF)     Do we need full object-oriented features?   18 November 2009   15 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   16 / 37
Inheritance
Inheritance allows more specific classes to be derived from more general
ones. It allows sharing of code that is common to the derived classes.

In the Animal example, we might want to have a separate class for Dog, to
express the fact that dogs are intelligent, and can rescue small boys from
disused mine shafts.

However, we also want dogs to use the Animal code for eating and playing.

In c++, we can do this:
c l a s s Dog : p u b l i c Animal {
private :
    double i n t e l l i g e n c e =50.0;
public :
    v o i d rescueTimmy ( ) { . . . } ;
};


    Mike Fisher (ECMWF)    Do we need full object-oriented features?   18 November 2009   17 / 37
Inheritance

We can then do this:
Dog l a s s i e ;
Animal babe ;
l a s s i e . eat ( ) ;
babe . makeNoise ( ) ;
l a s s i e . rescueTimmy ( ) ;


     lassie.eat() and babe.makeNoise() use the functions defined in the
     Animal class.
     Only lassie can be told to rescueTimmy(), because only dogs have
     this specialised ability.




    Mike Fisher (ECMWF)      Do we need full object-oriented features?   18 November 2009   18 / 37
Inheritance
Fortran 90/95 does not support inheritance, but it can be approximated.
We define a derived type that contains a component of type Animal:
module Dog module
  use Animal module
  type Dog type
      type ( Animal type ) : : the animal
      r e a l : : i n t e l l i g e n c e =50.0
  end t y p e D o g t y p e
contains
  s u b r o u t i n e rescueTimmy ( t h i s )
      type ( Dog type ) : : t h i s
      ...
  end s u b r o u t i n e rescueTimmy
end module Dog module


(NB: In Fortran 90/95, the contents of a derived type are either all public
or all private. I need the animal to be public, so I had to make intelligence
public, too.)
    Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   19 / 37
Inheritance
Things get a bit ugly when we want to access the functions from the
Animal “class”:
type ( Dog type ) : : l a s s i e
t y p e ( A n i m a l t y p e ) : : babe
c a l l e a t ( l a s s i e%t h e a n i m a l )
c a l l makeNoise ( l a s s i e%t h e a n i m a l )
c a l l e a t ( babe )
c a l l makeNoise ( babe )


Clearly, long strings of inheritance could get a bit ridiculous:
call multiply ( &
& l a s s i e%the mammal%t h e q u a d r u p e d%t h e a n i m a l%t h e b e i n g )


whereas, in c++, we would just do this:
lassie . multiply ();

    Mike Fisher (ECMWF)       Do we need full object-oriented features?   18 November 2009   20 / 37
Inheritance: Summary



    Inheritance is just about possible in Fortran, but quickly gets ugly.
    Essentially, we have to fake “is a” relationships (Lassie is a Dog) by
    using “has a” relationships (Lassie type contains an Animal type
    component).
    Fortunately, this type of simple taxonomy tree is of limited use in our
    applications.
    The real power of inheritance comes when it is combined with
    Polymorphism and Abstraction.




   Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   21 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   22 / 37
Polymorphism
Polymorphism refers to the ability to re-use a piece of code with
arguments of different types.

For example, suppose cg implements a conjugate-gradient minimisation
algorithm for vectors defined as real arrays of dimension 10000:
s u b r o u t i n e cg ( c o s t F u n c t i o n , s t a r t P o i n t )
external costFunction
real , dimension (10000) : : s t a r t P o i n t
...
end s u b r o u t i n e cg


Mathematically, the algorithm does not change if we we replace the array
argument by a distributed vector, a 2-D array, a vector of
observations, or a spectral field.

Ideally, we would like to have a single code that can be applied to all these
different types of arguments.
     Mike Fisher (ECMWF)           Do we need full object-oriented features?   18 November 2009   23 / 37
To return to our Animal example, suppose we have written many lines of
code, including hundreds of calls to the makeNoise() function.

We now want to make our application a bit more realistic by making dogs
say “woof!” and pigs say “oink!”.

In c++, all we have to do is:
c l a s s Dog : p u b l i c Animal {
public :
    v o i d makeNoise ( ) { c o u t << ” woof ! ” << e n d l ; }
};

c l a s s P i g : p u b l i c Animal {
public :
    v o i d makeNoise ( ) { c o u t << ” o i n k ! ” << e n d l ; }
};


The rest of the code stays the same.

    Mike Fisher (ECMWF)    Do we need full object-oriented features?   18 November 2009   24 / 37
In fortran, we would like to do something like this:
type Dog type
  type ( Animal type ) : : the animal
  c h a r a c t e r ( l e n =5) : : m y n o i s e=” woof ! ”
end t y p e D o g t y p e

type Pig type
  type ( Animal type ) : : the animal
  c h a r a c t e r ( l e n =5) : : m y n o i s e=” o i n k ! ”
end t y p e P i g t y p e

s u b r o u t i n e makeNoise ( t h i s )
type (???????) : : t h i s
p r i n t ∗ , t h i s%m y n o i s e
end s u b r o u t i n e makeNoise


This doesn’t work because this must be given a specific type (Animal or
Dog or Pig) at compile time.

    Mike Fisher (ECMWF)         Do we need full object-oriented features?   18 November 2009   25 / 37
It is possible to implement polymorphism in Fortran 90/95, by making the
base type contain pointers to all possible derived types (see, e.g. Decyk,
Norton and Szymanski, Computer Physics Communications, 115(9), 1998):
type Animal type
...
type ( Dog type ) , p o i n t e r : : d o g p o i n t e r
type ( Pig type ) , p o i n t e r : : p i g p o i n t e r
end t y p e A n i m a l t y p e

s u b r o u t i n e makeNoise ( t h i s )
type ( Animal type ) : : t h i s
i f ( a s s o c i a t e d ( t h i s%d o g p o i n t e r ) ) t h e n
    p r i n t ∗ , t h i s%d o g p o i n t e r%m y n o i s e
else
    p r i n t ∗ , t h i s%p i g p o i n t e r%m y n o i s e
endif
end s u b r o u t i n e makeNoise


But, it is not pretty! NB: Adding a new child type (e.g. Cat type) requires
changes to the base type and its functions.
     Mike Fisher (ECMWF)          Do we need full object-oriented features?   18 November 2009   26 / 37
Polymorphism: Summary
   Polymorphism is difficult in Fortran, but can partially be achieved
   through clever use of pointers and interface blocks.
   Adding a new possibility (e.g. a Cat) is straightforward in c++.
   In Fortran, it requires changes to the base type (Animal), and to all
   the interface functions that take Animal arguments.
   Polymorphism can also be implemented in Fortran using the Forpedo
   pre-processor.
   Full object-oriented languages provide a much more natural means to
   implement polymorphic code.
   There are several examples where polymorphism could be useful in
   the IFS:
         Minimisation algorithms applied in model space and observation space.
         Spherical transforms applied to distributed and single-processor fields.
         I/O routines applied to spectral and gridpoint fields.
         Observation processing of different types and subtypes.

  Mike Fisher (ECMWF)     Do we need full object-oriented features?   18 November 2009   27 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   28 / 37
Abstraction
Abstraction refers to the ability to write code that is independent of the
detailed implementation of the objects it manipulates. It allows algorithms
to be coded in a manner that is close to their mathematical formulations.

Take 4D-Var, for example. Mathematically, we have:
                                                    M
        1                           1
  J(x) = (x − xb )T B−1 (x − xb ) +                      (yi − Hi xi )T R−1 (yi − Hi xi )
                                                                         i
        2                           2
                                                   i=0



We can describe the algorithm in terms of a few objects: vectors and
matrices in model and observation space, and operators Hi (and Mi ).

These objects have a few simple properties: vectors can be added and
subtracted and their dot-product calculated, Hi can be applied to a
model-space vector and produces an observation-space vector, etc.

   Mike Fisher (ECMWF)   Do we need full object-oriented features?     18 November 2009   29 / 37
Abstraction

We should be able to write our algorithms in an abstract way, using
objects for which a minimal set of fundamental properties is assumed.

The description of the algorithm should be entirely independent of the
code that implements these properties.

An algorithm written in this way can then be applied to any set of objects
that implements the fundamental properties.

Thus, for example, once we have coded a 4D-Var algorithm, we should be
able to apply it without modification to a wide range of models.

Only object-oriented languages provide the tools required to do this.



    Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   30 / 37
Abstraction
Example: In c++, we might implement a Vector class as follows:
c l a s s Vector {
public :
    v i r t u a l Vector   &   o p e r a t o r =( V e c t o r &)=0;
    v i r t u a l Vector   &   o p e r a t o r +( V e c t o r &)=0;
    v i r t u a l Vector   &   o p e r a t o r −( V e c t o r &)=0;
    v i r t u a l Vector   &   o p e r a t o r ∗ ( d o u b l e &)=0;
    v i r t u a l double   &   d o t w i t h ( V e c t o r &)=0;
};


Although the syntax is a little alarming, this simply amounts to a
mathematical definition of vectors: specifically, that they can be added,
subtracted, multiplied by a scalar and the dot-product calculated.

The “virtual” and “=0” parts of the definition indicate that the precise
implementation of these properties will be given later, in a class derived
from Vector.
    Mike Fisher (ECMWF)        Do we need full object-oriented features?   18 November 2009   31 / 37
Abstraction
Although we have not specified exactly how to add, subtract, (etc.)
Vectors, we can still write (and compile) code to manipulate them:
Vector u , v , w;
double d ;
u=v ;
w=u+v ;
w=u−v ;
d=u . d o t w i t h ( v ) ;
u=d∗w ;


Using this technique, we can for example, code the entire 4D-Var
algorithm in terms of a handful of abstract classes (State, Increment,
Departure, etc.), each of which has a few abstract properties.

To apply the code to a particular model (Lorenz 3-variable, QG, IFS, etc.),
we simply define a set of derived classes that implement these abstract
properties. The 4D-Var code remains identical for all the models
     Mike Fisher (ECMWF)      Do we need full object-oriented features?   18 November 2009   32 / 37
Abstraction: Incremental 4D-Var on One Slide!
void incremental 4dvar ( CostFunction4dvar & J ,                                       // compute i n i t a l c o s t and g r a d i e n t
                         ControlVariable & x ,                                         dx = 0 . 0 ;
                         Observation & y ,                                             J . s i m u l ( dx , gx , z j 0 ) ;
                         i n t & nouter ) {
                                                                                       // CG M i n i m i z a t i o n
  C h a n g e V a r i a b l e S q r t C o v a r c h a v a r ( 1 , ∗J . B ) ;           CG( J , dx , gx , 4 ) ;
  double zj0 , zj1
  int jout ;                                                                           // Compute f i n a l c o s t and g r a d i e n t
                                   −
  i n t c t l s i z e = J . B >c v e c s i z e ( ) ;                                   J . s i m u l ( dx , gx , z j 1 ) ;
  C o n t r o l V e c t o r dx ( c t l s i z e ) , gx ( c t l s i z e ) ,
                                 da ( c t l s i z e ) ;                                // Form i n c r e m e n t and a n a l y s i s
  dx = 0 . 0 ;                                                                         // i n p h y s i c a l s p a c e
  da = 0 . 0 ;                                                                         I n c r e m e n t ∗ dxtmp ;
                                                  >g
  T r a j e c t o r y t r a j ( J . hmop4d− e t n s t e p ( ) ) ;                      dxtmp=J . g e t B()−> g e t i n c ( ) ;
                                                                                       I n c r e m e n t a l C o n t r o l V a r i a b l e x i n c ( 1 , ∗ dxtmp ) ;
  f o r ( j o u t =0; j o u t < n o u t e r ; j o u t ++ ) {                           c h a v a r . v e c t 2 v a r ( dx , x i n c ) ;
                                                                                       ∗ x i n c . g e t ()=∗ x i n c . g e t ()+∗ x . g e t ( ) ;
     D e p a r t u r e ∗ ydep ;                                                        da = da+dx ;
     ydep=J . g e t R()−> g e t d e p ( ”ombg” ) ;                                 }

     O b s e r v a t i o n ∗ yeqv ;                                                // F i n a l d i a g n o s t i c s
     y e q v=y . c l o n e ( ” o b s v ” ) ;                                       C o n t r o l V a r i a b l e xwork ( 1 , x . g e t ( ) [ 0 ] ) ;

     // S e t u p t r a j e c t o r y and d e p a r t u r e s                      O b s e r v a t i o n ∗ yeqv ;
                                                                                   y e q v=y . c l o n e ( ” o b s v ” ) ;
     C o n t r o l V a r i a b l e xwork ( 1 , x . g e t ( ) [ 0 ] ) ;             J . get hmop4d ( ) . n l ( xwork , ∗ yeqv , t r a j ) ;
     J . get hmop4d ( ) . n l ( xwork , ∗ yeqv , t r a j ) ;                       D e p a r t u r e ∗ ydep ;
              >d
     ydep− i f f (∗ yeqv , y ) ;                                                   ydep=J . g e t R()−> g e t d e p ( ”oman” ) ;
                                       >p
     i f ( j o u t == 0 ) ydep− u t d b ( ) ;                                              >d
                                                                                   ydep− i f f (∗ yeqv , y ) ;
     t r a j . s e t ( da ) ;                                                              >p
                                                                                   ydep− u t d b ( ) ;
     t r a j . s e t (∗ ydep ) ;                                               }
     J . s e t t r a j ( traj , chavar ) ;

        Mike Fisher (ECMWF)                             Do we need full object-oriented features?                        18 November 2009                33 / 37
Abstraction

A typical abstract type:
c l a s s Increment {
public :
      Increment (){};
      v i r t u a l I n c r e m e n t ∗ c l o n e ()= 0 ;
      v i r t u a l I n c r e m e n t & o p e r a t o r =( I n c r e m e n t &)=0;
      v i r t u a l I n c r e m e n t & o p e r a t o r =( c o n s t d o u b l e &)=0;
      v i r t u a l I n c r e m e n t & o p e r a t o r ∗ ( c o n s t d o u b l e &)=0;
      v i r t u a l I n c r e m e n t & o p e r a t o r +( S t a t e &)=0;
      v i r t u a l d o u b l e d o t p r o d u c t ( I n c r e m e n t &)=0;
      v i r t u a l v o i d r e a d ( c o n s t c h a r ∗)=0;
      v i r t u a l v o i d w r i t e ( c o n s t c h a r ∗)=0;
      v i r t u a l I n c r e m e n t & p r o p a g a t e t l ( M o d e l T r a j e c t o r y &)=0;
      v i r t u a l I n c r e m e n t & p r o p a g a t e a d ( M o d e l T r a j e c t o r y &)=0;
};



    Mike Fisher (ECMWF)          Do we need full object-oriented features?   18 November 2009   34 / 37
Abstraction
The code on the last two slides is the same for all models, from Lorenz ’63
to IFS.

To plug a given model into the system, we must provide derived classes for
each of the abstract classes, which implement the virtual functions defined
in the abstract classes.

For example, Increment requires us to specify 11 functions. For the QG
model, most of these are trivial (4–10 lines of code), so that the derived
type QgIncrement is 100 lines of code.

In QgIncrement, the functions propagate tl and propagate ad call Fortran
routines to perform a timestep of the tangent-linear and adjoint model,
respectively.

Nearly all the computational work is done in the Fortran code.

    Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   35 / 37
Outline

1   Definition of “Object-Oriented”


2   Encapsulation


3   Inheritance


4   Polymorphism


5   Abstraction


6   Conclusions


     Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   36 / 37
Conclusions

    Several techniques of object-oriented (OO) programming can be
    emulated in Fortran 90/95.
    However, the techniques are not natural to the language, and require
    some rather convoluted code.
    Changes (e.g. adding a new class) that can be achieved with a few
    localised modifications in C++ may require widespread changes in
    Fortran 90/95.
    A significant clean-up of the IFS could be achieved without requiring
    OO techniques by proper use of modules and encapsulation.
    However, the full power of an OO language is required if we want to
    separate our algorithms from their implementation and produce a
    fully flexible, model-independent code.
    A flexible code is vital if we are to evaluate and implement new ideas
    in data assimilation.

   Mike Fisher (ECMWF)   Do we need full object-oriented features?   18 November 2009   37 / 37

								
To top