In article <90268DDEBaledainupnawaycom@203.59.24.169>,
nospam@nospam (Alex) wrote:
> [posted and mailed]
>
> wim@hoeijenbos.demon.nl (Wim Hoeijenbos) wrote in
> <978959759.8179.0.pluto.c3adf994@news.demon.nl>:
>
> >One of the big advantages of OO programming in C++, JAVA etc is the
> >inheritance of membervars/methods from parent Class to Child. This is
as
> >far as I know not possible in GOOP.
>
> AFAIK Jorgen Jehander has previously written in this newsgroup that
this is
> possible. The technique is called inheritance by delegation, and
involves
> embedding the derived classes in the base class and using an attribute
that
> decides which embedded class to call.
>
> Perhaps Jorgen can explain this further.
>
> --
>
> Alexander C. Le Dain, PhD
> ICON Technologies Pty Ltd
> http://www.icon-tech.com.au
>
> ******************************************************************
> * The LabVIEW FAQ http://www.icon-tech.com.au/thelabviewfaq.html *
> ******************************************************************
>
>
Inheritance in GOOP
Abstract
By utilizing the power of inheritance in LabVIEW, the programs become
more flexible and easier to maintain.
General theory
Object-oriented programming extends classes to allow for subclass
relationships. This is achieved through a mechanism referred to as
inheritance.
Let us illustrate this by having two classes called Function_Generator
and HP33120A. HP33120A is a specialization of a function generator since
it represents a real generator. Using the inheritance mechanism we would
have the HP33120A to be a subclass to the base class,
Function_Generator. This means that the HP33120A class will inherit
behaviour, methods, from the Function_Generator class. In many cases you
put common code for all subclasses in the base class that is reused by
the subclasses. In our example it could be code handling the GPIB
communication to all different types of function generators. The
different strings used for instrument specific commands are handled in
the subclasses, in our case the HP33120A class.
Let us add a method called Frequency to both classes.
Think of some test cases only interested in setting the frequency of a
function generator. The test cases do not want to be affected when new
function generators are added. How do you program that? Traditional
LabVIEW code would access the HP33120A directly. So what would happen if
the function generator is changed to a Tektronix AWG 2041generator. We
would have to change all code using the HP33120A. Is not there a smarter
way to hack this? The trick is to use the powerful inheritance scheme
and add a TEK_AWG_2041 subclass . Let the code in the test cases only
call a Function_Generator object. When the code is actually executed the
Function_Generator object is transformed into the right type of function
generator, in our case a HP33120A or a TEK_AWG_2041 object. The key
thing is that the transformation to exact type of object is done in run
time and not when you place the code in the block diagram. This means
that the block diagram code for the test cases only contains code for
handling a Function_Generator. Normally this transformation scheme is
called dynamic binding since the actual binding is done in run time. The
beauty with that is that the code in the test cases will not be affected
when new types of function generators are added to the system. When a
new function generator is added it only has to be defined at one place
in the program, not in all test cases. The code becames robust for
changes and that makes the code easier to maintain.
Inheritance is based primarily on these two concepts:
1. An inheritance relationship between a base class and its subclasses
2. Dynamic binding
Inheritance in GOOP
The GOOP model today cannot implement the concepts above directly so
they have to be simulated. A technique called "Inheritance by
deligation" is used.
An aggregation relationship is used to implement the inheritance
relationship. A base class aggregates, embedds, its subclasses. In our
example the Function_Generator class would aggregate the HP33120A and
the TEK_AWG_2041 classes.
The dynamic binding is done inside the base class. An attribute, private
data member, called current subclass is added to the base class. An
enumerated type is used for the current subclass attribute and the
integral constants are the names of the subclasses. This attribute
controls the dynamic binding in the following way. When a call is done
to a method in the base class a check is done on value of the current
subclass attribute. Depending on the value the call is dispatched,
deligated, to the right type of subclass object.
In our example we would rename the attribute to current function
generator and it would contain two integral constant called HP33120A and
TEK_AWG_2041.
Summary
A drawback with the simulation model for inheritance in GOOP is that it
is more time consuming to manage as compared to true inheritance in
languages like C++ and Java. Anyway, the benefit from using inheritance
in LabVIEW greatly exceeds the time it takes to learn and deploy it. By
using it large LabVIEW projects becomes feasible to maintain.
Sent via Deja.com
http://www.deja.com/
