From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-02-27 18:59:34
John,
Allow me to paint a clearer picture on objects vs components. First,
what components are, why they are cool, and why they are not cool. I
gave a demo at Comdex of a component-based system using Java Beans
(true components). It was a control system for home appliances. It
consisted of a collection of different beans (components). Some beans
were appliance controllers, they were logically associated with
hardware, in this case X10 appliance control modules. Other beans
were lamp controllers, they were logically associated with X10 lamp
controllers. These two beans are different because they behave
differently: appliances go on/off, but lamps go on/off and also
dim/bright. Other beans were used to represent timers, events, scenes,
etc. We had a GUI tool (bean box) for "snapping together" components.
The end user, who is NOT a programmer, has a "palette" of components
(beans) to choose from, and a workspace to build his own home
controller. He drags beans (with mouse) from the palette onto the
workspace (GUI bean box), each bean represents a real peice of hardware
(lamp, coffee maker, toaster, television, etc). The user then drags
other beans onto the workspace (bean box) to represent events and
preprogrammed "scenes". He may use a timer bean to switch lights on
and off to make it appear that he is home when he's not. He may program
a "scene" for watching movies, which is a sequence of events: turn on
the TV and VCR, dim the lights, and start the popcorn maker. This movie
scene is what we did at comdex. Maybe he has a "romance" scene to dim
the lights and play soft music when entertaining the ladies.
Each of these components has a very rigid interface. They have to be
rigid because otherwise they cannot work with something like a "bean
box" (builder tool), and they cannot interface with each other in the
dynamic way of "assembly" of components. This works well with many
different small parts that can be fit together like a jigsaw puzzle.
But componentizing for the sake of modularity, reuse, etc is not the
answer for all systems. Components don't and can't behave like true
objects. They cannot implement abstract interfaces, they must be
concrete and self-contained. They must have certain persistant
characteristics (they must be able to serialize themselves). They
must contain properties that can be queried by a "bean box" or
builder tool, or by other components. Their interfaces must be very
rigid so they can "snap together".
Here's another similar example. I worked on some biotech industrial
automation stuff with Java. It was much more complex than home/
appliance control, but it has the same problems/opportunities. The
end users are automation engineers, not programmers. They know how to
assemble PARTS to make a SYSTEM. The parts may be valves and motors,
thermometers and guages, etc. You can make ANYTHING out of these
various parts. Each part is very specific and it behaves in a very
specific way, it also interfaces in a very specific way. Here is a
good opportunity for a "bean box" type "builder tool" with drag and
drop and associate, just like my home control demo. The automation
engineers would love it. But we did not do it. Why? It takes a LOT
of work and a LOT of time/money to cook something like this. We
estimated several man-years effort. How many man-years do you want
OpenEEG to go through to get to Alpha 1.0 public release?
I am actually trying to work out some kind of a component architecture
for wearable computers. Again it's a similar problem/opportunity. I
have many different types and sources of inputs like switches,
keypads, keyboards, voice control, audio from multiple sources. I
also have many different outputs, to normal monitors, to small flat
panel displays, head mounted displays, small text LCDs, audible
messages, audible prompts. By making components I can mix and match
inputs with outputs, I can easily shift from video to audio displays
etc. Each of these "modalities" BEHAVES differently, even it's
doing the same thing, data needs to get formatted differently, or
the sequences of user action may differ. This is not a trivial
thing to build, and to get it right reqires a lot of thought. I
will be happy to have something decent in a year or two ....
Now back to OpenEEG. What PARTS do we have? There aren't very many.
We have data from devices, but all of the data is similar, even if
it's EEG vs ECG vs GSR vs TEMP. All of that data BEHAVES in similar
ways, they are samples over time and measured in frequency. So one
PART is just DATA that represents a sensor. Another part is spectral
analysis. We may have one or many methods (FFT, digital filtering,
wavelets, etc) but they all BEHAVE in similar ways. We have displays
of waveforms. We may have many of these, but they all behave in
similar ways. Aside from that we have some configuration and "user
session" data, and some "neurofeedback protocol" event handling.
The FLOW of things is always going to be the same: from sensor
(input) to filter (analysis) to display and/or NF protocol. You
certainly could make these into true components, but there is
really no need to have a "pallete" of PARTS where you mix and
match these things in different ways. If you did, it would be
pointless, you'd always do the same thing: associate a sensor with
a filter and display and an event. This can all be done in a simple
GUI, no true components are needed. In fact, OpenEEG fits object-
orientation better than componentization. There are three key
things to object orientation:
1) Inheritance - Objects exists as generic types and then are
sub-typed to more specific types. We should have a sensor
class. All sensors have some things in common. Sub-types
may be EEG or ECG or GSR or TEMP. There may be some minor
differences in the subtypes, but all sensors are sensors.
This is powerful as a model of process, since we can ask
ANY sensor to do something and assume that ALL sensors
can do that something (see polymorphism below).
2) Encapsulation - Objects encapsulate data and behavior,
unlike procedural systems. Objects should be like little
black boxes, it should not matter HOW they work, only
that they work. In this respect they are sort of like
components, but they AREN'T because components have a
much more strict set of rules.
3) Polymorphism - Because of #1 and #2 above, we can treat
objects in a ploymorphic way. The classic example is a
shape, all shapes have certain properties, they can be
drawn, they have an area, etc. So a SUPER shape class
contains the properties of ALL shapes, but the SUB types
contain specifics. By following this rule, we can say
shape.draw() to ANY shape and it draws. There is great
power in this model.
Java is so nice to proram with because of its collection
of classes, and also it's handling of memory. Usually
you grab an existing class and extend it. It already has
most of the methods you need. This is what we want to
build for OpenEEG: a set of classes, each with the
right set of BEHAVIOR and management of DATA. If we do
this right, it will be very flexible. If we try to make
it into a component system, it will be very rigid. There
is a LOT of power in having abstract interfaces. They
only FORCE the interface NOT the implementation of the
interface. This means that what might be a visual to
Jim might be an audible to me. Components cannot deal
with abstract interfaces by their very definition.
Also, event handling is forced with components in such
a way that is restrictive.
Java Beans are just like MS COM (Common Object Model)
components. These are way too over-hyped. They are
supposed to be a big collection of PARTS that you can
BUY and SNAP TOGETHER and voila you have an accounting
system or medical system. I've done a LOT of systems
analysis and design in my days, from goals/objectives
to project defns, general and detailed designs, on to
programming, testing, and implementation. I have yet
to see a real system that works well with components.
Can you buy any Java Beans? Or more appropriately,
WOULD you buy them? Nobody is buying them. The IT
industry is full of hype, OO and components is part
of it, and much of it is politics. The CORBA people
make big bucks for their "black magic" because there
is VERY FEW people who can even make sense of it!
Components have their place, but as I said, they are
powerful when MANY DIFFERENT parts are assembled in
many different combinations to build different kinds
of things. We're not doing that. We're building some
very specific procedures here. And BOTH the data and
behavior fit well into an object model. So that is
where ALL of the real design work lies, in an object
model. And paper is better than automated tools for
that purpose. We probably only have a handful of
different objects.
-- Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST