Model programming of j2se5.0 new features

This chapter mainly refers to Sun company documentation.



C + + programmers are certainly not unfamiliar with fan-type programming, especially when the STL is a big line, c#2.0 will also realize the function of paradigm programming. Java is not outdone, but also introduced the paradigm of programming language new features.



1. A simple Paradigm example

In the past, you might have encountered code like this:
List List = NewLinkedList (); List.add ("MIT"); List.add ("Princeton"); List.add ("Berkeley"); StringName = ( String) List.iterator.next ();

Note that the third line requires a cast. Instead, use the paradigm:
list< String> list = Newlinkedlist< String> (); List.add ("MIT"); List.add ("Princeton"); List.add ("Berkeley"); StringName = List.iterator.next ();
The list is declared here as a String type list. List is a generic interface with a type parameter. In this example, the type parameter is string.



2. Define a simple paradigm

See the implementation of the list and iterator interfaces in j2se5.0 (fragment):
Public Interfacelist<e> { voidAdd (E x); Iterator<e> Iterator (); } Public Interfaceiterator<e> {E next (); BooleanHasnext (); }
The above code is familiar to us, but it adds angle brackets. The contents of the angle brackets define the form type parameters of the interface list and iterator. Type parameters can be used in generic declarations, such as declarations of classes and interfaces.

Once you've declared the paradigm, you can use it. In the example above, list<string> is used. Here the string is the argument, instead of the formal parameter E. If you use List<integer&gt, the argument Integer is used instead of the formal parameter E.

Whether list<integer> or LIST&LT;STRING&GT, they have only one class. Consider the following code:
list< String> List1 = Newlinkedlist< String> (); list< Integer> List2 = Newlinkedlist< Integer> (); System. Out.println (List1.getclass () ==list2.getclass ());

The output is true.



In general, formal type parameters are uppercase, use a single letter as much as possible, and many container classes use e as arguments.



3. Paradigm and inheritance

Consider the following code, do you think it will go wrong.
Strings = "smallnest@163.com"; Objecto = s:
Of course, the string class inherits the object class and does so without error. But the following code does.
list< String> s = Newlinkedlist< String> (); list< Object>o=s;

Compilation error.

Yes,,list<object> and list<string> have no inheritance relationship.



4. Wildcard characters

Consider one of the following methods:
Public voidPrintcollection (collection< Object> C) { for( ObjectO:C) { System. out.printf ("%s%n", O); } }
In fact, the above method is not universal, it can only print a collection of collection<object> types, like other collection<string>, collection<integer> cannot be printed because the object type is inconsistent.

In order to solve this problem, you can use a wildcard character:
Public voidPrintcollection (collection<. > C) { for( ObjectO:C) { System. out.printf ("%s%n", O); } }
collection<. > is called a collection of unknown types. Question marks represent various types.

When we read the data in the collection above, we take the object type. This is possible, because regardless of what type the unknown type ultimately represents, its data inherits the object class, then consider the following code:
collection<?> C = Newarraylist< String> (); C.add ( New Object()); //!!!!
This is wrong, because we don't know what type to represent, so we can't add object directly to the collection, which can happen with a type mismatch.



5. Restricted wildcard characters

Consider the following code
classMan { Public Stringname = "";} classGoodMan extendsMan { Public StringName = ""} classBadman extendsMan { Public StringName = ""}
Consider the following paradigm-based approach:
Public voidPrintname (list<man> men) { for(Man Man:men) { System. Out.println ("Name:" + man.name); } }

This paradigm method can only display data of type list<man>, and the following code allows the display of man and its subclasses.
Public voidPrintname (list<. extendsMan> men) { for(Man Man:men) { System. Out.println ("Name:" + man.name); } }
Use here? Extends man, instead of man, indicates that the subclass of any man is accepted as a parameter.

Similar to the previous code, the following code is also incorrect:
Public voidAdman (list<? extendsMan> men) {GoodMan good = NewGoodMan ();    Good.name = "Shi"; Men.add (good); }
The reason is also very simple, because? on behalf of all the classes that inherit the man, you cannot guarantee that the Goodman class will be.



Similar to this usage:
Public voidAdman (list<? SuperGoodman> men) {GoodMan good = NewGoodMan ();    Good.name = "Shi"; Men.add (good); }
6. Paradigm Method

Consider the following code, where we add the contents of an array to a collection
Public voidCopyarraytocollection (man[] men, collection<?>c) { for(Man Man:men) {C.add (man);} }
This piece of code is wrong.

Because we do not know the type of the collection C, we cannot add the data of the man type to the collection.

You can use the paradigm approach to solve:
Public<T> voidCopyarraytocollection (t[] men, collection<t>c) { for(T man:men) {C.add (man);} }
Here T is a formal type parameter.

When to use a common approach. When to use a wildcard character.

Consider the following example:
Interfacecollection<e> { Public BooleanContainsall (collection<?> c); Public BooleanAddAll (collection<? extendsE> c); }
Rewritten as a universal method
Interfacecollection<e> { Public<T> BooleanContainsall (collection<t> c); Public<t extendsE> BooleanAddAll (collection<t> c); }
However, here each method T is used only once, the return value does not depend on the formal parameter, and the other parameter does not depend on the formal parameter. This indicates that the argument is used as a polymorphic, in which case the wildcard character should be used.