Re: Fitzle

[furgalj@xxxxxxxxxxxxxxxx]

Gary wrote:

>This is just a point of curiosity on my part.  What category would the
>following scenario fall under,inheretance, extension?  Can anyone give
>me an example of how this would be accomplished in OO and/or procedural?
>
>You have an object called a fitzle.  It has three properties.  1. It can
>hold data.  2. It can have data written to it.  3. It can have its data
>read....

OK, at the risk of embarrassing myself, I'll take a stab at this.

First, the 3 "properties" that you mention aren't really what I would call 
properties. They are just common operations that many kinds of data 
structures are able to do.

>You want to use this fitzle object in several ways but you need a few
>additional properties for each.  First, you want it to be usable for
>displaying data.  You also want to use it to format data being printed.
>Thirdly, you want to organize data in this fitzle object in a particular
>sequence.

>So for all three you feel you need to add the properties "type of file",
>"device type", "record format".

The kinds of things you are describing are again, not properties. They are 
uses of the information contained in or managed by the fitzle. Rather than 
inheritance or extension, these uses are now called patterns. Patterns 
came from architecture, and I mean buildings, gardens, and plazas, not 
software design. The architect Christopher Alexander has been exploring 
patterns for at least 30 years.

To be brief, Alexander studied structure and spaces, and the way we 
interact with them. He found that there were certain uses of buildings and 
their spaces that always seemed to work well. Things like having multiple 
light sources, furniture groupings away from traffic areas, etc. He called 
these common uses patterns. At some point in the late '80's or very early 
'90's, some folks here in Illinois (U of I, Naperville Bell Labs), and a 
few other places, realized that this same approach could work with best 
practices in software development. Based on surveys and interviews with 
quite a few large scale development projects, a book was written. It was 
the now classic, "Design Patterns: Elements of Reusable Object-Oriented 
Software," by Gamma, Helm, Johnson, & Vlissides.

I'm sorry if I'm going over old ground for you, but from your question I 
thought some of this was in order. The basic concept here is to leave your 
fitzle alone and adapt a set of standard usage objects around it. 
Displaying fitzle's information, either on a terminal or a printer, 
shouldn't change much of anything. Sun shows how to do this with their 
Java Swing package. A video display and a printer are both just different 
types of devices. You perform the same operations on each. This is how you 
achieve re-use. The fitzle should never have to know where or how its 
attributes are being displayed.

Do you want to sequence a fitzle's data? Fine, leave it alone. Just create 
a standard collection object, such as a list or a tree, filled with 
fitzle's repeating attributes. Then sort however you want using a 
Comparable object, or change the keys to the tree. Now you have reused not 
only the same old fitzle, but a standard Java Collection class, and a 
Display and a Printer device context.

In terms of patterns that were used, treating visual display and printing 
the same way is called the Facade pattern. Performing repetitive work with 
collections of attributes would be an example of the Iterator pattern.

PROCEDURAL PROGRAMMING ALERT!

Now on to a topic that seems to be giving everyone fits. Let me sit over 
the tub of cold water with my clown face on and say that JAVA IS A 
PROCEDURAL LANGUAGE. Most OO languages are, such as Smalltalk and C++. An 
example of a non-procedural language would be SQL, and (takes a deep 
breath) RPG when dealing with the report cycle. That's right, RPG is less 
procedural than Java! The OO aspects of Java and Smalltalk are all 
procedural. They just take advantage of a large symbol space within the 
compiler, and hidden pointers. When Java uses OO features like inheritance 
and polymorphism, it is just passing the work up or down the object 
hierarchy. The work is still executed procedurally, it's just that the 
decision as to who will execute the work is deferred until run-time. 
Better yet. These decisions can often be made without "if" statements, via 
the use of virtual pointers. Sometimes you even get a bit of a speed-up do 
to less branch logic.

Fire away everybody. I think I just saw a troll under a toadstool in my 
backyard -). But really, I am serious.

I hope this helped. If you haven't already seen it, take a look at the 
Design Patterns book, or one of the many rewrites for more modern 
languages (it was aimed at C++ programmers).

_________________________________________________________________
Jeff Furgal / MIMIX User Interface Product Architect / Lakeview Technology

furgalj@xxxxxxxxxxxxxxxx / 630-282-8360

LAKEVIEW TECHNOLOGY CONFIDENTIAL

This e-mail may contain SECRET, PRIVILEGED AND/OR CONFIDENTIAL INFORMATION 
intended only for the use of the addressee.  If you are not the addressee, 
or the person responsible for delivering it to the person addressed, you 
may not copy or deliver this to anyone else.  If you received this e-mail 
in error, please immediately notify Lakeview by returning the original 
message to the sender via e-mail.