From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-02-28 06:14:51
John,
There is a good brief intro on the difference between functional
orientation and object orientation here:
http://www.cranfield.ac.uk/sims/quality/quality2/cpd_courses/cpp_intro.html
I am obviously a proponent of object orientation. We spoke about
RMI earlier, what got me hooked on RMI is the fact that it is a
truly object oriented distributed system, the only one that I am
aware of. What this means is that it preseres polymorphism even
across machine/memory boundaries. I can create a heierarchy that
represents an object (supertype and subtypes) and pass that as
an argument is a remote method call. If the calling process is
local, it will "pass by reference" (ie pointer), but if it's
remote, it will "pass by value", it will serialize that object
in its entirety and reconstruct it on the other side.
Take the classic OO example of polymorphism: shapes. I create
a generic shape super type. I then create sub-types for circle,
square, and triangle. All shapes have methods that are in
common, as represented in the supertype. I can pass any shape
around anyhwhere and it will have a shape.draw() method. The
code that operates on shapes intetionally does not know about
the uniqueness of the subclass (unless it has to). The shape
ITSELF takes care of its drawing, not the code around it. In
the old world we would do
if circle then
blah
else if square then
blah
else if triangle then
blah
And we would do that in many places. In OO we don't do that,
we specifically avoid that, instead we operate on the notion
of polymorphism, we say shape.draw() or shape.getArea() etc,
we never reference a circle or square or triangle. Later
when we add new subtypes (polygon), NONE of the code has to
change, the polygon ITSELF knows what to do (everything that
is specific about polygons), and the super type is what all
or at least most of the code operates on. The cool thing
about RMI is it can preserve this polymorphism across the
wire. The bad thing about RMI is that there is a lot of
overhead in doing this. The passing of a raw stream of data
like EEG data is a perfect example where RMI is the wrong
tool for the job, probably IP sockets would work.
Apply these concepts of inheritance, encapsulation, and
polymorphism to EEG. Think entities and relationships first.
We have sensors, filters, displays, users, configurations,
etc. Most of these can and will exists in heirarchies of
supertypes and sub-types. If we think carefully on this we
can come up with just a dozen or so objects. Then we work
on methods, for both the super and sub types. From there
we examine the relationships and figure out how to apply
design patterns like MVC for event handling. My proposal
then is not to think about EEG data and EEG functions,
instead we should be thinking about sensor entities and
entities that relate to sensors. We could break this down
functionally, and componentization would probably do that,
but I'm a proponent of OO, an if we don't do OO then I
will do it anyways.
Now, let's go back to your question, you said that when
you compile C++ you get an .EXE (executable). All native
code compilation involves two steps, creation of an
object module, then linking to a loadable or executable.
When you compile a C program, it creates .o files first
(object modules) and the final link creates the end
result, often an single executable as you say. But there
are different kinds of linking: static and and dynamic.
Static linking goes out into the libraries referenced
and copies the code into the executable. Dynamic linking
does NOT copy the code, it refers a shared library. A
statically linked program is self-contained, it needs
nothing else, and chews a lot of ram in the process.
A dynamically linked program will resolve the symbol
table at RUNTIME and load the necessary code ON DEMAND
from shared libraries. So we DON'T end up with one big
honking huge memory hog executable, we create a small
main program, we create shared libraries, and the C++
program loads only what it needs on the fly. The only
COST is disk space, and this won't be a huge system.
-- Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST