RE: Fitzle -- JAVA400-L

Jeff,

Thanks for your explanation.  It puts the raging debate into perspective
for me.



----------------------------------------------------
This mailbox protected from junk email by MailFrontier Desktop
from MailFrontier, Inc. http://info.mailfrontier.com


-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of
furgalj@xxxxxxxxxxxxxxxx
Sent: Friday, July 09, 2004 9:03 PM
To: java400-l@xxxxxxxxxxxx
Subject: Re: Fitzle


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.
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.