Re: OO Factory
- From: "Oliver Wong" <owong@xxxxxxxxxxxxxx>
- Date: Mon, 28 Nov 2005 20:02:59 GMT
"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:dYHif.636350$oW2.188085@xxxxxxxxxxx
>
> Not being snarky Chuck, but above left me in mid-air. I can't confirm that
> following is 100% conforming to J4 Standard, but for Oliver's info., here
> is what the N/E 4.0 on-line manual illustrates :-
>
> *>------------------------------------------------------------------------
> Interface Source Elements
>
> You write your interface definitions in interface source elements. An
> interface source element can contain one or more interface definitions.
>
> The code block below shows the outline of an example interface source
> element. An ellipsis (...) shows where code has been omitted, and
> indentation indicates the levels of nesting. In this example the interface
> Drivable, containing a method prototype for calculating mileage, inherits
> from the interface Rentable, which can be assumed to contain methods
> applicable to all objects that can be rented.
What N/E 4.0 calls "Interface", Java calls "abstract class". Java also
has something called "interface", which is somewhat like N/E 4.0's
"Interface", except that in Java, interfaces cannot have any code for their
methods. They can declare the names of methods, and what parameters are
expected to get passed in and out (like the "USING" and "RETURNING"
clauses), but absolutely no code.
[snip]
>
> A parameterized interface is a skeleton interface that has one or more
> formal parameters. When you provide specific class names or interface
> names as actual parameters, the Compiler expands the parameterized
> interface into a new non-parameterized interface. The purpose of
> parameterized interfaces is to make it easier for you to create many
> similar interfaces.
In Java, (Java-)interfaces, abstract classes and "normal" classes can
all be parametrized this way, so the term used is "parametrized type", but
it sounds like it's exactly the same concept. Parametrized types was
introduced in Java 1.5, which came out about 1 year ago, so you won't find
references to it in older books, and sometimes you'll see posters on the
comp.lang.java.* groups who are unaware of it.
Some people (myself included) feel that the concept of parametrized
types itself is good, but that the way Sun put it into Java was rather poor.
In Sun's defense, the poor implementation had a lot to do with keeping Java
1.5 backwards compatible with previous versions, but as a result of this,
we've lost a lot of the power inherent in the idea.
[snip]
> Russell was dealing with abstracts; possibly not the correct word but
> 'proto-typing'. He was giving you a Lego toolkit to put
> collections/dictionaries together in almost any fashion you liked, (your
> lists/maps, in Java). Your phrase went something like, "Suppose you don't
> know which class you want....." - he was going down the same path.
> Reflecting back to the final lines of his response to me, "...... I've
> since moved on from COBOL and now I program in Java.....". No wonder I
> found his document complex - it was obviously from his association with
> Java that he managed to concoct his abstractness !
Yes, when Java 1.5 was released, parts of the Sun's standard class
library was rewritten to take advantage of parametrized types. The biggest
success story in this rewrite was the API for collections. Previous in Java,
you had Lists into which you could put things, and take them out, but you
had no real way of enforcing that only certain types of things could be put
into any given list. So you might, for example, in one part of the code, put
an object of type A, and then elsewhere, mistakenly assume your list
contained only objects of type B, and tried to extract such an object, which
would cause an error not at compile time, but at runtime, and only when the
actual extraction tried to take place.
With the new syntax added, instead of just having "List", you would have
"List<A>" which meant that the list could only contain objects of type A,
and this could be checked at compile time, thus making it easier to catch
such bugs.
We actually switched from using Java 1.4 to Java 1.5 at my workplace
while I was working there, and we actually discovered a bug like this during
the switch. We had a List called "users", which was obviously a list of
users. Unfortunately, in one location, rather than actually placing objects
of type User into the list, numbers were being placed in the list, these
numbers being the user-id of the user.
It just so happened that that portion of the code was being run so
rarely (never) that we never noticed the bug until we switched to Java 1.5
- Oliver
.
- Follow-Ups:
- Re: OO Factory
- From: James J. Gavan
- Re: OO Factory
- References:
- Re: OO Factory
- From: James J. Gavan
- Re: OO Factory
- Prev by Date: Re: Multilingual conversion - Ideas ?
- Next by Date: Re: Multilingual conversion - Ideas ?
- Previous by thread: Re: OO Factory
- Next by thread: Re: OO Factory
- Index(es):
Relevant Pages
|
