From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-02-28 00:55:03
> Allow me to paint a clearer picture on objects vs components. First,
<< SNIP >>
> builder tool, or by other components. Their interfaces must be very
> rigid so they can "snap together".
That is what I WAS thinking of. :-(
> Here's another similar example. I worked on some biotech industrial
<<SNIP>>
> estimated several man-years effort. How many man-years do you want
> OpenEEG to go through to get to Alpha 1.0 public release?
DAM :-( I bow to your greater knowledge!!
> 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:
OK sounds good!
I was only thinking of mixing a matching between layers.
EG hardware to a filter, a trigger object and a recorder....
Single source multiple destinations!
> 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).
Very eloquently put and what I was trying to say. :-(
> 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.
Yes I understand the difference and what you were alluding to now.
> 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
NOT the shape example....ahhhhhhhh :-) Every class on poly uses it. :-))
> 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.
Most defiantly!
> Java is so nice to program 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
YES!!!
> 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.
OK throw away components!!! :-)
Long live OBJECTS !!!!
> 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!
HAHAHAHA yeah in one of my classes the lecturer said he was going to avoid
CORBA because of it's complexity!!
and it was a class dealing with that type of technology.
> 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.
Hay sounds great so out with components and in with Objects. :-)
I'm more comfortable with classes and objects anyway. :-)
So we don't have to try doing ASCII art is there any GUI UML program that
you prefer.
Rational rose, visio, ??
Preferable free or shareware?
and we can start bouncing designs around and get something started. :-)
> -- Doug
A BIG thanks for your input you have stated what I was fumbling with very
sinsinctly and stoped IT going up the blind ally of components.
Great working with you!!!!!!!!!!!
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST