patterns09 - generics in .net and java
TRANSCRIPT
Introduction
There is a common technique available in
Java (versions 1.5 and above) and .net
(version 2 and above).
The Generic Datatype
Overloading and polymorphism go a long
way towards making an object oriented
system work ‘properly’
But they only take you to the bridge.
The Problem
Let’s say we want to create a basic data
structure.
One that works for any object.
It’s something straight forward – a queue,
for example.
How do we do that?
Well, in older versions of a language we’d
declare the data type as an Object.
The Queue Public class Queue {
ArrayList<Object> myObjects;
void addToQueue (Object ob) {myObjects.add (ob);
}
void removeFromQueue () {Object ob = myObjects.get(0);myObjects.remove (0);return ob;
}}
The Problem We can use casting to turn whatever is on the
queue into whatever class we need:Person p =
(Person)queue.removeFromQueue();
This is bad OO. It’s not type safe
We need to enforce discipline to make sure that we don’t put the wrong things on the wrong queues. The compiler should be doing as much of that
as is feasible.
The Solution
Both C# and Java offer the Generic as a
solution.
A class which acts as a type-safe template.
The syntax is a little awkward, but it allows
us to define the type that should be
associated with a data structure.
Like we do with ArrayLists.
Queue – Java Genericimport java.util.*; public class Queue<T> {
ArrayList<T> myList; public Queue() {
myList = new ArrayList<T>(); } public void addToQueue(T ob) {
myList.add(ob); } public T getFromQueue() {
T ob = myList.get(0); myList.remove(0); return ob;
}
public boolean hasMoreElements() { return (myList.size() != 0);
} }
Queue – Java Genericpublic static void main(String args[]) {
Queue<String> myQueue = new Queue<String>();
myQueue.addToQueue("Hello!"); myQueue.addToQueue("World!"); while (myQueue.hasMoreElements()) {
System.out.println(myQueue.getFromQueue());
} }
Queue – C# Genericclass Queue<T>
{
ArrayList myObjects;
public Queue ()
{
myObjects = new ArrayList();
}
public void addToStack<T>(T ob)
{
myObjects.Add(ob);
}
public T removeFromStack()
{
T ob = (T)myObjects[0];
myObjects.RemoveAt(0);
return ob;
}
}
}
Why Use Generics?
Type safe – we can ensure type incompatibilities are dealt with at the earliest possible opportunity.
Simplifies syntax – no need to cast individual objects.
Allows for effective deployment of certain kinds of design patterns.
Avoids the need for excessive specialisation of classes.
How do they work?
It is important to know the different ways
in which variables are bound during the
running of an application.
Traditionally variables are bound to a
specific context in one of two ways.
Static binding, which is done at compile
time.
Dynamic binding, which is done at runtime.
Static Binding
Explicitly indicating the type of a
parameter allows for the compiler to link
objects and variables when compiled.
They’re not going to change in that
respect.
The performance of this is high, and
compile-time checking can be rigorous in
a way that’s not possible otherwise.
Late Binding
Late binding is used extensively in Java and C#.
One key area in which it is used is in polymorphism.
When you use Polymorphism, Java adopts a late binding approach so that it can properly adapt to the object at runtime.
It knows the most specialised method to use when invoked, but only when the object is bound.
Strongly Typed Languages In strongly typed languages, early binding is
the norm. We can tell what the context is going to be by
analysing the runtime
However, late binding needs to be dealt with either through polymorphism or compile time casting.
Generics allow for you to defer the binding of a data type until its point of usage arrives. The <T> parameter is unbound.
When we instantiate the class, we bind it to a specific context.
Boxing and Unboxing
In both Java and C# a related
mechanism is known as autoboxing.
This is the process of converting a value
variable into an object reference, or vice
versa.
When a value reference is boxed, it is
stored on the ‘managed heap’.
A chunk of memory set aside and tended
by the garbage collector.
Wrapper Classes
Each primitive data type in Java and C#
comes with a corresponding wrapper
class.
A class designed to provide a way of
dealing with it as a reference.
It used to be impossible to have an
ArrayList of ints in Java.
You needed to make them Integer objects
first.
Wrapper Classes
Autoboxing then is the process at play when a primitive data type is encapsulated within a wrapper.
And vice versa, when it is unwrapped into its primitive form.
Autoboxing is a relatively expensive process.
If you were doing this a lot, it would be worth assessing your specific data manipulation requirements.
Generics and Constraints
All of this leads to an obvious problem.
What if we don’t want everything to be on
the table for a generic?
Luckily, generics allow us to set constraints
on them.
Limitations that restrict what can be a valid
specification of our class.
There are six types of these in .NET.
ConstraintsConstraint Description
Where T: struct The type argument must be a value type.
Where T: class The type argument must be a reference
type.
Where T: new() The type argument must have a public,
parameterless constructor
Where T: <class name> The type argument must extend from the
indicated class name.
Where T: <interface
name>
The type argument must implement the
specified interface, or be the interface itself
Where T: U The type argument for T must be or derive
from the argument supplied for U.
Exampleclass Queue<T> where T : IComparable
{
ArrayList myObjects;
public Queue ()
{
myObjects = new ArrayList();
}
public void addToStack<T>(T ob)
{
myObjects.Add(ob);
}
public T removeFromStack()
{
T ob = (T)myObjects[0];
myObjects.RemoveAt(0);
return ob;
}
public Boolean isInQueue(T ob)
{
T ob2;
for (int i = 0; i < myObjects.Count; i++) {
ob2 = (T)myObjects[i];
if (ob2.CompareTo(ob) != -1) {
return true;
}
}
return false;
}
}
Constraints
Multiple constraints can be applied to the same parameter.
And in turn, they can be generic in and of themselves.
If you are going to be performing operations on a type that are not defined in Object itself, you need to apply a constraint.
That will allow for the method to be made available in a type-safe way.
Multiple Parameters
Some classes may provide two types.
For example, Hashtables
T and U are used conventionally to refer
to parameter 1 and parameter 2.
You can apply separate constraints to
each of these:
Where U : class
Where T : iComperable
Unconstrained Types
With unconstrained types, we have the
following restrictions:
We cannot use simple logical comparators
on them, because there is no guarantee
the concrete type will support them.
They will need to be formally cast.
You can compare to null, but this will
always return false if the type argument is a
value type.
Conclusion
Generics offer a new and powerful way to deal with type-safe collections.
And other kinds of classes.
Constraints allow us to ensure that we can access useful methods as required.
Polymorphism will ensure that we can reliably access whatever internals we require.
They’re available in both C# and Java.