Chapter 5 Design and Implementation
5.1 The object oriented structure
In object-oriented programming theory, polymorphism is the ability of objects
belonging to different types to respond to method calls of methods of the same name,
each one according to an appropriate type-specific behavior. The programmer (and the
program) does not have to know the exact type of the object in advance, so this
behavior can be implemented at run time (this is called late binding or dynamic
binding).
The different objects involved only need to present a compatible interface to the
clients (the calling routines). That is, there must be public methods with the same
name and the same parameter sets in all the objects. In principle, the object types may
be unrelated, but since they share a common interface, they are often implemented as
subclasses of the same parent class. Though it is not required, it is understood that the
different methods will also produce similar results (for example, returning values of
the same type). [16]
For this benefit, we use the object oriented paradigm to design the Visualization
Metaphor Programming Paradigms. With the object oriented paradigm, the DIVINE
system can just use the same routine call to all the different VM designing by different
VM programmer. It will reduce the change of the system code in the future.
Figure 5-1 Inheritance architecture of Visualization Metaphor
Figure 5-1 shows the class diagram of the Visualization Metaphor Programming
Paradigms. The DIVINEVM class extends the OgreVMObject to be a 3D object,
extends the observer class to be an observer of Observer Pattern and implements the
abstract action method to interaction with the 3D user interface.
The ObjectVM, CompositeVM and RelationVM are extended from the
create the abstract class DIVINEVM to be the super class of the three VM classes.
In the future, maybe more different type VM would be defined, but have the
same attribute and method, so it can just extends from the DIVINEVM rather then
define the attribute and method itself.
5.2 The interaction of debugging objects and VM object
The Observer Pattern defines a one-to-many dependency between a subject
object and any number of observer objects so that when the subject object changes
state, all its observer objects are notified and updated automatically.
The following is class diagram and sequence diagram of an observer pattern:
Figure 5-2 The class diagram of an Observer Pattern.
Figure 5-3 The sequence diagram of an Observer Pattern.
In the Visualization Metaphor Programming Paradigms, we are using the
Observer Pattern to make the debugging object updating the changed data
automatically. The reason of why we use this pattern is it can automatically update the
changed date rather then the VM programmer should take care of the data changed in
the debugging object.
The debugging object extends the subject class to be a concretesubject. The VM
extends the observer class to be a concreteobserver. When the VM is chosen to be a
representation of a debugging object, the VM will be attach to the debugging object.
In the constructor of the VM, it will register the variable to the Mapping Engine.
When the debugging object data changed, the subject will notify the entire observer to
update. The Update method of each observer will be called to update the variable
which registers to the Mapping Engine.
aSubject
Data Changed
Notify()
aObjectVM
Update()
RenderEngine
draw()
draw()