Aug 17

We already learned in previous examples that assignment of instances of the subclass to a list of upper classes is working without problems:

a.add(new SalesPerson());
a.add(new ControlingStaff());

Let’s have a look on overwritten methods, eg

class SalesPerson extends Employee{String getName(){ return(“SalesPerson”);}}
class ControlingStaff extends Employee{ String getName(){ return (“ControlingStaff”);}}

Those functions can be called directly without any error/warning since there is during runtime no difference between Array and ArrayList:

System.out.println(a.get(0).getName()); // Output: SalesPerson
System.out.println(a.get(1).getName()); //Output: ControlingStaff

Tagged with:
Aug 14

Let’s go even deeper in the tricks of generics in methods and change the definitions therefore a little bit:

List <SalesPerson> a = new ArrayList <SalesPersonr>();
a.add(new
SalesPerson());
a.add(new
SalesPerson());

SalesPerson i [] = {new SalesPerson(), new SalesPerson ()};

The methods remain unchanged:

public static void checkStatus_array (Employee[] a){ … }
public static void checkStatus_list (List<Employee> a){ … }

Also here we are calling the appropriate functions :+

checkStatus_list(a); // CompilerError
checkStatus_array(b); // compiling and running without problems

In both cases “SalesPerson” is transfered and type “Employee” taken over. For Arrays it is working smoothly, but not for List; a cast does not take place. Therefore always the exact object-type need to be transfered.  In contradiction to assignments a explizit cast is not helpful in this case.

 

Tagged with:
Aug 11

Let’s have a look on an 2 similar methods:

public static void checkStatus_array (Employee [] a){ … }
public static void checkStatus_list (List<Employee> a){ … }

Intentionally they should work similar, what do you think?

First of all the definitions:

List <Employee> a= new ArrayList <Employee>();
a.add(new SalesPerson());
a.add(new ControllingStaff());

Employee b [] = {new SalesPerson(), new ControlingStaff ()};

Calling the own methods is smoothly:

checkStatus_list(a);
checkStatus_array(b);

In contradiction calling the methods of each other lead to CompilerError:

checkStatus_list(b);
checkStatus_array(a);

Tagged with:
Aug 07

First of all an extended comprehension before we are going into the specials of generics; let’s start with the following declarations:

Employee () { … }
SalesPerson extends Employee () { … }
ControllingStaff extends Employee () { … }

A cast in an upper class is possible without problems:

Employee a = new SalesPerson ();
Employeer b = new ControllingStaff ();

Same is applicable for arrays:

Employee [ ] c = {new SalesPerson(), new ControllingStaff () };

But this is not working for Collections:

List <Employee> b = new ArrayList <SalesPerson>();

What is working is the assignment of sub-classes to the collection of the upper class :

List <Employee> d = new ArrayList <Employee>();
d.add(new SalesPerson());
d.add(new ControllingStaff());


No warning is produced, the code is working fine through the hole program-flow.

Tagged with:
Aug 04

As we already know there is no problem in assigning different Collections on the base-object:

List <Integer> a= new ArrayList<Integer>();

It seem to be clear, that it should work with object-types in the same way, but this is not the case:

import java.util.List;
import java.util.ArrayList;
class Employee{

public static void main(String args[])
{

List <Employee> b = new ArrayList <SalesPerson>(); // CompilerError
SalesPerson a = new SalesPerson();

}

}
class SalesPerson extends Employee{ }

The rule behind is quite easy: declaration of types and transfer need to match exactly, although it is different for arrays;

Employee [ ] c = new SalesPerson[3]; is working without problems – so don’t get confused during certification :)

Tagged with:
Aug 01

Let’s have a closer look on method get() due to the error-proness during runtime:

For non-generics the return-value of get() is a reference to java.lang.Object, for generics a reference of the determined object-type. This means that for non-generics a turn into a primitive value can not take place since unboxing is only refereing to a wrapper (respectively their class-reference). A cast can help out in this case:

List <Integer> a= new ArrayList<Integer>(); // generic
a.add(3);
int b = a.get(0);
//assignemnt to int-value without problems due to Wrapper


List c = new ArrayList ();
// non-generic
c.add(3);


int d = (Integer)c.get(0);
// assignment is only possible with explicit cast since reference of java.lang.Object was returned

Tagged with:
preload preload preload
http://www.wikio.de Blog Top Liste - by TopBlogs.de Blogverzeichnis - Blog Verzeichnis bloggerei.de Bloggeramt.de Software
Webbhotell Top Blogs