From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-03-01 11:43:33
Jim,
>> Perhaps there are other commands and/or responses from
>> the microcontroller that should be wrapped in getter
>> and setter methods. We really should start thinking
>> hard about sensors as generic entities.
> I'm not the best person to discuss this with. I've
> probably been too much influenced by using Perl and
> the UNIX environment. After all, UNIX is a component
> system that has been working well for a long long
> time
Well, I don't want to have wars over this, but if we
do C++ it makes sense to do OO style modeling.
> I would say, why not initialise a sensor device with a
> command-line string, or with a 'hash' of config-file
> values ? Saying "-r 120" is much less to type.
The whole idea is encapsulation. The methods in the
object that describe the sensor (in this case eeg)
contain ALL fnctions that it can or cannot do. There
are many good reasons to do this. The best reason is
that it's self-documenting and consistent all over a
system. Take a look at the Java APIs for an example
of this done very well. Then end result is an API
that makes sense.
My wearable code is like this. If I create a display
interface, I first create JUST an interface that is
only method signatures. Then I create an object that
implements that interface. In that object, it talks
to a microcontoller (just like in OpenEEG). Now here
is the power of OO and abstract interfaces. If I
change display hardware, move to a new display that
uses different escape codes, I only change the code
in that one ENCAPSULATED place, all other code is
the same. If I change microcontrollers, and use a
new microcontroller with different communication,
say I2C instead of RS232, again it is completely
separate from the application. Think of it this way,
on one side you have FUNCTION like println(blah),
this is a method signature (which makes up a well
known and STABLE API). How that function is done
is not known by the rest of the code, and that is
how it should be. The boundary between the real
application code (that which calls println) and
the DEVICE code (ugly detail) is an interface
that only forces behavior, it purposely does not
implement, because implementations change. As an
example, in the Java world it would be like this:
public interface display {
print(String text);
}
public class displayDevice implements display {
print(String text) {
// low level code here
// here we have escape codes and such
// here we talk to microcontrollers
}
There are at least four good reasons to do
it this way:
1) We encapsulate all behavior of a device in
a well defined object class
2) We separate the implementation detail from
the code that calls it, allowing detail to
change without apps changing.
3) It is very well documented. You can look at
any device or function and know all of its
methods by their signature.
4) If there is a sensor super-type, you can
call ALL sensors and say setSampleRate(120).
If you want to configure a device with a command-line
string then you are considering that device to be a
program, there is no programming interface (API). You
can still have your command-line options if you want
but it would be better if they called an object.
> Also, as you may have noticed, anything I code myself
> will probably end up looking like a console application,
> as that is the place I call home. It will be 90%
> keyboard oriented, because that makes it very fast to
> operate. No fiddly widgets to click! No wasteful
> hand-mouse-pointer-eye-hand feedback loop just to press
> a button!
Jim, I love console apps, I'm not a fan of GUIs, but
your stuff needs to fit in with other stuff in the
bigger picture. The interaction between all of these
parts won't be keyboards, they will be calls from
other processes.
> However, probably some people will be wanting to move
> towards a fancy GUI, so that Windows people and mouse
> users feel like they are in control. This is not an
> area that I feel happy with -- trying to create something
> I'm not going to enjoy using is not a recipe for success!
Keep in mind that biofeedback is probably going to
be graphic, and you really don't want to be thinking
about command line options and syntax while you are
trying to slow your brain down. For the average person
the command-line options just won't work.
Namaste,
Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST