[Tutor] impact of OO

[alan.gauld@bt.com]

> informative and reassuring, although also eye-opening -- 
> there is a lot ahead to learn.  

In programming there always is its why I'm still here.
In OOP its even more so because the rules and definitions 
are still not fully drawn up and agreed.

> What is a JavaBean?  

A component in Java terminology.
Its an object which has methods for getting and setting 
its attributes which follow a naming convention 
(getXXXX, setXXXX etc). The advantage of this is that 
tools can query the innards and provide some dynamic
capabilirties at design time(live database tables in 
a GUI desiner for example).

Its a horrible hack like most things in Java and 
Python's 'properties' specifiers(borrowed from Delphi!) 
are much nicer IMHO.

> between Java 2 and Java 2 Enterprise Edition.  

If anyone knowsw better please jump in, as y'all may have 
figured out I'm a fairly reluctant Java user!
Java 2 is just a development of the basic Java platform 
with some new classes and frameworks(GUI bits and security 
stuff etc) J2EE is a different beast entirely and is all 
about producing large scale (Enterprise) computing 
platform with middleware, systems management, persistency, 
transactional support etc. Its kind of Suns alternative 
to Microsofts .NET/COM+ architectures. Its one of the few 
bits of Java that I don't hate completely, although it 
is pretty complex - most powerful things are!

I'm sure somebody else can give a better story than that!

> Are you contrasting a huge, well-developed library with a 
> class hierarchy, or are you suggesting that they are similar?  

In Java and many other OO lanbguages they are the same. The 
whole library is implemented as an enormous class hierarchy 
starting with a top level 'Object' class.(Delphi/Kyliix 
and Smalltalk both take this approach.)

> suppose this is the luxury of a compiled language, that you 
> do not need to provide modules and libraries and ensure 
> that your user has access to the interpreter to be able 
> to run the code.)  

Correct, BUT you still need those modules and libraries 
to *build* the code so from the languagfe provider/programmer 
view it dsoesn't make much difference, only the end user 
sees the gain....

> bundle of code to use, a hierarcy of objects (like JavaScript's 
> "Document Object Model") helps the programmer to intuitively 
> know what can be done with various branches of the code 
> because it is similar to other branches of the code.  

That's the theory. How well it works depends on the skill 
of the heirarchy designer. I only need to mention MFC v1 
to have the grey beareded ones amongst us cringing from 
the memory! Comparing MFC with the new .NET CLR GUI 
classes shows the difference a good heirarcxhy design 
can make.

One of the disadvantages of C+++ vv Java is that C++ libraries 
are much les well integrated, Java has one enormous and 
mostly consistent heirarchy, C++ has traditionally used lots 
of mini heirarchies from lots of different designers. The new 
Standard Library partially addresses this but its scope is 
far more limited than Java's library of classes.

> where polymorphism is useful, so that you can use a branch of code 
> quickly and similarly to another branch of code that you are already 
> familiar with.

Absolutely - see Pythons parser/formatter modules for 
examples of how polymorphism is used in that way in a library.

> But I have made an assumption about what you meant, and I 
> could be wrong.

I don't think you are far away.

> How is Python's organization less tree-like than Java's?  

Consider the string module. Its functional in form and not 
related to any other classes. Similarly the sockets module.
In this respect Pythons library is more like C++ in that 
some modules are related to each oither but most are 
decoupled. Because of Pythons dynamic capabilities this 
is much less of a problem than in a strictly typed language 
like C++ (where type inconsistencies between modules cause 
huge headaches)

> related to the phrase "in Java everything is a class" that 
> was mentioned last week (I think Alan suggested this)?

Only accidentally. Because everything in Java is a class and 
all Classes must inherit from Object then all library 
"functions" translate to methods of a class which in 
turn is part of a single object heirarchy. BUT many Java
library functions(type conversion for example) are static 
methods which means that they udse classes exactly like 
we use non OO modules. You can call a Java static method 
via the class you don't need to instantiate an object.

Java is riddled with this and one reason I call Java 
"class oriented" rather than "object oriented". Java 
programmers call these static methods class methods but 
even that is a distortion of proper classs methods. 
Class methods should e used to act on the class as 
a whole not to convert a single instance into another 
type - yekkk!

> to take advantage of the similarity between an object and a 
> database row in my code at work, but it's still very new to me.

Here be dragons. The analogy breaks down rapidly when you 
introduce inheritance. Which table do inherited attributes 
live in? Do you have a key linking the parent object table 
to the derived object table and then get the SQL to JOIN 
them? Do you create a view to produce a virtual table of 
both classes? Or do you create a new superset table for 
the derived class? Whole books and learned papers have 
been written on how to map the OO paradigm to relational 
databases.

Alan G.