An Introduction to Generics in Java – Part 2

This is a continuation of an introductory Generics tutorial, previous part of which can be found here.

Generics Instantiation Syntax

In the previous post we have learned how to declare a generic class. We have also learned its formal definition. Now it’s time to learn how to create instances of the generic class, formally.

To create an instance of a generic type, we do generic type invocation, which replaces the type parameter with a concrete type. We have seen multiple examples of this in the previous article. Remember our MyPrettySimpleGenericClass from the previous post? If you don’t, here is the definition -

public class MyPrettySimpleGenericClass<E> {
  private E item;

  public void setItem(E item) {
    this.item = item;
  }

  public E getItem() {
    return item;
  }

  public void printItem() {
    System.out.println(item.toString());
  }
}

Then, to create an instance of this class, we do the following -

MyPrettySimpleGenericClass<Integer> item = new
    MyPrettySimpleGenericClass<Integer>();

In the above code, we have performed a generic type invocation by replacing the type parameter with a concrete type Integer, which makes this object to work with all the integer values. We call Integer a type argument in this case. An invocation of a generic type in this way creates what we call a parameterized type. Our parameterized type in this case is MyPrettySimpleGenericClass<Integer>.

You can pass any non-primitive type as a type argument. You can even pass another parameterized type too, because they are also non-primitive. Consider the following example -

MyPrettySimpleGenericClass<List<Integer>> item = new
    MyPrettySimpleGenericClass<List<Integer>>();

In the above example, the type parameter is another parameterized type, which was obtained by parameterizing the List<E> generic interface (it’s part of the standard Java API, specifically the Collection API and I intend to write something about them too!).

You can see that this generic method invocation thingy looks somewhat similar to method invocation, except that during a method invocation you pass values as arguments (yes, Java is pass-by-value, and if you are wondering about it, please have patience as I intend to write a post about it in future), and here you pass types as arguments.

Now, some of you might be wondering about the constructor syntax of a generic type, after seeing the <Integer> part right before the parentheses in the above code. Do we also have to put type parameters in the constructor of a generic type?

Short answer – No. You declare a constructor of a generic type like any other constructor. You don’t need to put a type parameter right before the constructor parentheses (in fact you’ll get a compilation error if you try something like that) – putting it right after the class name is enough, unless your constructor itself is a Generic Method (I promise I won’t run away until I write a post about it) which introduces a new type parameter!

In JDK 7 and later, you can omit the type argument during the invocation of the constructor of the generic type, provided that the compiler can determine, or infer (yes, Type Inference will be coming up in a future post), the type argument from the context. Taking advantage of this feature, we can modify our previous object instantiation in the following way -

MyPrettySimpleGenericClass<Integer> item = new MyPrettySimpleGenericClass<>();

This pair of angle brackets, right before the parentheses, is conventionally known as the diamond. It’s of great convenience when writing generics  as you have to type less.

Enough theoretical stuff. Let’s put all these things together and write something useful, because the best way to learn something is by actually doing it.

A Useful Example – Implementing a Generic Stack

In this example, we will build a Stack. This stack will be generic – we will use it for different types of items based on different type arguments.

Let’s see the declaration of our Stack class -

import java.util.NoSuchElementException;

public class Stack<E> {
  private long size;
  private long count;
  private StackElement top;

  private class StackElement {
    private E element;
    private StackElement next;
  }

  public Stack() {
    this(Long.MAX_VALUE);
  }

  public Stack(long size) {
    this.size = size;
    this.count = 0;
  }

  public long getSize() {
    return size;
  }

  public long getCount() {
    return count;
  }

  public boolean isEmpty () {
    return count == 0;
  }

  public boolean isFull () {
    return getCount() == size;
  }

  public void push (E element) throws UnsupportedOperationException {
    if (isFull()) {
      throw new UnsupportedOperationException("Push operation is " +
        "not supported on full stack");
    }

    StackElement elem = new StackElement();
    elem.element = element;
    elem.next = top;
    top = elem;

    count++;
  }

  public E pop() throws NoSuchElementException{
    if (isEmpty()) {
      throw new NoSuchElementException("Stack is empty");
    }

    StackElement topElement = top;
    top = top.next;
    count--;

    return topElement.element;
  }

  public E peek() throws NoSuchElementException {
    if (isEmpty()) {
      throw new NoSuchElementException("Stack is empty");
    }

    return top.element;
  }
}

Some points about the above stack implementation -

1. We generally use arrays to store stack elements. This approach won’t work here, because we cannot create an array of generic types. Instead, we will be using the Linked List implementation.
2. We have created an inner class to represent a linked list element. This is a perfect example of when an inner class should be used. We wanted to make a type which will store an element of type E, and will also hold a reference to the next element. If we make it a top-level class, we won’t be able to access the type parameter E from it. So, we needed a type which will have access to internal information of another type. As a result, we use an inner class (yes, more on inner classes will come next, in the near future, perhaps within the next ten years…..hmmmmmm……..).
3. Notice that we have declared our inner class as private. If we don’t declare it as such, then it may also be accessed from outside Stack, thus leaking our implementation detail in the outside world.
4. Notice the declaration of push, pop and peek method. The first one throws an UnsupportedOperationException if an element is pushed while the stack is full, and the last two throws a NoSuchElementException when these operations are done in an empty stack. Some might think of using other exception classes, or building their own with more customization. As for this example, it’s a simple one, so I will be using these two.

Ok, now let’s see a simple test drive -

public class Main {
  public static void main(String[] args) {
    Stack<Integer> intStack = new Stack<>();
    intStack.push(10);
    intStack.push(20);
    intStack.push(30);
    while(!intStack.isEmpty()) {
      System.out.println(intStack.pop());
    }

    Stack<Double> doubleStack = new Stack<>();
    doubleStack.push(10.5);
    doubleStack.push(20.34);
    doubleStack.push(30.56);
    while(!doubleStack.isEmpty()) {
      System.out.println(doubleStack.pop());
    }

    Stack<String> stringStack = new Stack<>();
    stringStack.push("Hello");
    stringStack.push("to");
    stringStack.push("Generics!");
    while(!stringStack.isEmpty()) {
      System.out.println(stringStack.pop());
    }
  }
}

See how we are using our stack for different types? Aren’t generics awesome ?

Play with it as long as you want. Tweak the example in as many ways as you like. Try creating an Integer stack and pushing a string into it. Do it the other way round. See what errors/exceptions you get. Also, try to implement other data structures, like Queue, with generics. See how awesome they become!

I have put this implementation in my github repository along with couple of simple test cases (yes, if it was a production quality code, there would have been more and more test cases), in case anyone wants to play with it.

And this is where I’d like to finish the second part. Hope to see you soon!

An Introduction to Generics in Java – Part 1

Generics play an important role in the development of Java applications. They provide stronger type checks at runtime, reduce the amount of typecasting needed and help to develop algorithms/procedures that can be reused for multiple types. In this series I will try to write a short tutorial about them.

A typical Generics Use Case – Implementing a Sorting Algorithm

Rather than learning generics by definition, let’s try learning it from one simple use case – implementing Insertion Sort.

We all know how Insertion Sort works. We are given an array of elements. Then the algorithm removes one element from the array, repeat over the existing ones, find the appropriate place for the removed element, and then inserts it there.

Let’s consider a simple implementation of this program in Java -

public class InsertionSort {
  private int[] elements;

  public int[] getElements() {
      return elements;
  }

  public void setElements(int[] elements) {
    this.elements = elements;
  }

  public void sort() {
    if (this.elements == null || this.elements.length <= 1) {
      return;
    }

    int i;
    for (i = 1; i <= elements.length - 1; i++) {
      int valueToInsert = elements[i];
      int holePos = i;

      while (holePos > 0 && valueToInsert < elements[holePos - 1]) {
        elements[holePos] = elements[holePos - 1];
        holePos--;
      }

      elements[holePos] = valueToInsert;
    }
  }
}

The above class implements a simple insertion sort algorithm. To sort an array of elements, we can use this class in the following way -

public class Main {
  public static void main(String[] args) {
    int[] elements = {3, 7, 4, 9, 5, 2, 6, 1};
    InsertionSort insertionSort = new InsertionSort();
    insertionSort.setElements(elements);
    insertionSort.sort();
    elements = insertionSort.getElements();

    // print the sorted array
    System.out.println();
    for (int i = 0; i < elements.length; i++) {
      System.out.print(elements[i]);

      if (i + 1 != elements.length) {
        System.out.print(", ");
      }
    }
    System.out.println();
  }
}

Now what if we want to sort array of floats, or doubles? Or, array of some custom objects? Can we use the above implementation for those cases?

No. Period.

The above algorithm only sorts simple integers. It cannot sort doubles, or floats, because in Java you cannot pass array of doubles to a method which expects an array of integer. So, if you want to sort doubles or floats, you’ll have to write another implementation which will then sort an array of doubles.

This approach has some serious drawbacks. For one, you’ll now have to maintain two different sorting algorithms, just to ensure that they operate on different types, even though the algorithm to sort them is exactly the same. From the principles of good Object Oriented Design, we know that this is bad, really really bad.

So, how can we change this implementation so that it works for doubles, or better yet, works for any types which can be compared with each other? Let’s pause for a moment here and try to think it by ourselves.

Really, don’t go read the next section. Thinking about why we need, or should use a language feature will help us to truly master it and use it effectively in our application.

Generics to the Rescue!

Ok, so you thought it through, right? If this is the case, then carry on!

What we will do is that we will somehow parameterize the above class so that it will now take types as its argument. This way, we will pass a new type as its argument whenever we will create a new instance of this class, which will then enable us to use the above algorithm for that type!

This is exactly what generics do! They enable types to be parameters when defining classes, interfaces and methods! From the official Oracle Java tutorial page -

In a nutshell, generics enable types (classes and interfaces) to be parameters when defining classes, interfaces and methods. Much like the more familiar formal parameters used in method declarations, type parameters provide a way for you to re-use the same code with different inputs. The difference is that the inputs to formal parameters are values, while the inputs to type parameters are types.

Let’s see the implementation first, then we will slowly understand how to write generics in the code and what syntax to use -

public class InsertionSort<E extends Comparable<E>> {
  private E[] elements;

  public E[] getElements() {
    return elements;
  }

  public void setElements(E[] elements) {
    this.elements = elements;
  }

  public void sort() {
    if (this.elements == null || this.elements.length <= 1) {
      return;
    }

    for (int i = 1; i <= elements.length - 1; i++) {
      E valueToInsert = elements[i];
      int holePos = i;

      while (holePos > 0 && valueToInsert.compareTo(elements[holePos - 1]) < 0) {
        elements[holePos] = elements[holePos - 1];
        holePos--;
      }

      elements[holePos] = valueToInsert;
    }
  }
}

Now, let’s dissect the above implementation to understand the syntax of generics -

1. Take a look at the first line, the class declaration. Notice the extra <E extends Comparable<E>> part which is new? This is the part which adds generic behavior to the previous implementation. Here, E is the type parameter. We will go into the syntax details in the next section.
2. Take a look at the elements declaration. After you declare a type parameter in the class declaration, you can then use it to declare a reference of that type. In our case, it’s an array.
3. Similarly, our setter and getter now takes and returns array of type E, respectively.
4. Take a look at the condition check inside the while loop, in the sort method. It has been changed to use the implementation of the Comparable interface. Keep a note of this because it will be explained in a later post.

and voila! With the above changes we can now use this class for lots of different types, provided that they all are of non-primitive types (yes, Generics don’t support primitive types) and implement the Comparable interface (this is to make sure that the elements can be compared with each other).

A sample use of the above class is as follows -

public class Main {
  public static void main(String[] args) {
    /**
     * Use the object wrapper for integer, because
     * generics don't support native types. The
     * following line will work due to Autoboxing.
     */
    Integer[] arr = {3, 7, 4, 9, 5, 2, 6, 1};

    /**
     * Check out the following line. It demonstrates
     * the way to pass type arguments to the
     * type parameters.
     */
    InsertionSort sort = new InsertionSort();
    sort.setElements(arr);
    sort.sort();
    arr = sort.getElements();

    System.out.println();
    for (int i = 0; i < arr.length; i++) {
      System.out.print(arr[i]);

      if (i + 1 != arr.length) {
        System.out.print(", ");
      }
    }
    System.out.println();

    /**
     * Let's use the implementation for
     * doubles!
     */
    Double[] anotherArray = {3.5, 7.2, 4.4, 9.45, 5.01, 2.50, 6.9, 1.11};
    InsertionSort anotherSort = new InsertionSort();
    anotherSort.setElements(anotherArray);
    anotherSort.sort();
    anotherArray = anotherSort.getElements();

    System.out.println();
    for (int i = 0; i < anotherArray.length; i++) {
      System.out.print(anotherArray[i]);

      if (i + 1 != anotherArray.length) {
        System.out.print(", ");
      }
    }
    System.out.println();
  }
}

Cool, eh ?

Generics Declaration Syntax

To declare a class as a generic one, we use the following format -

class name<T1, T2, ..., Tn> { /* ... */ }

The portion delimited by angle brackets in the type parameter section where you define the type parameters (they are also called type variables sometimes). The above declaration specified n type parameters – T1, T2, ….., Tn, and is called a generic type declaration. A type variable can be anything – any class type, interface, array or anything else, provided that it’s a non-primitive type.

After you declare a class in the above way and specify a type parameter, you can then use it like any other type inside that class, subject to the following conditions -

1. You cannot create an instance of a type parameter.
2. You cannot declare any static field whose type matches a type parameter.
3. You cannot typecast or use instanceof operator with type parameters.
4. You cannot catch or throw objects of parameterized types.

I know that the example I’ve provided looks more complex than the simple declaration syntax above. Keep your patience, I will certainly explain it in a future post (if I don’t, you are given the permission to poke me with a stick).

Let’s see another simple declaration of a generic class -

public class MyPrettySimpleGenericClass<E> {
  private E item;

  public void setItem(E item) {
    this.item = item;
  }

  public E getItem() {
    return item;
  }

  public void printItem() {
    System.out.println(item.toString());
  }
}

and a simple use case -

public class Main {
  public static void main(String[] args) {
    MyPrettySimpleGenericClass<Integer> item = new MyPrettySimpleGenericClass<Integer>();
    item.setItem(20);
    item.printItem();               // prints 20 to the console

    MyPrettySimpleGenericClass<Double> anotherItem = new MyPrettySimpleGenericClass<Double>();
    anotherItem.setItem(39.60);
    anotherItem.printItem();        // prints 39.60 to the console
  }
}

So now we’ve seen a simple use case of Generics. Thankfully that wasn’t too complex to understand.

That’s it for today, folks. Hopefully I will write the next post of this series pretty soon. If anything in the current post seems difficult to understand, or if you find any errors, please feel free to comment in!

JavaScript Rants Part One – Simple Objects and Properties

For so long I have been wanting to write some posts about JavaScripts! Today I finally managed to find some time to write the first one of them! This will be the first post in a series of posts about JavaScripts. Today my writing topic will be simple objects and properties.

Objects

In JavaScript, objects are just collection or propertieswhere a property is just a key-value pair. A simple JavaScript object may look like this -

var obj = {
    key: 'my value'
};

That’s it. It’s as simple as that. Any kinds of objects, no matter how complex it is, can be summarized to just a key-value store.

Creating objects and properties

There are basically three common ways to create objects in JavaScript. Each of them is illustrated in the following example -

/* 1. The object literal syntax. It's the most simplest
 * form of object creation.
 */
var obj = {};

/* 2. With the Object.create method, specifying the prototype
 * for the object. ECMAScript 5+ only.
 */
var anotherObj = Object.create(null);

/* 3. With Object constructor
 */
var lastObj = new Object();

All of the above three methods create an empty object which has no property. They all appear to be doing the same, creating an empty object with no properties, but this is not the case.

Each of the above three methods have their own advantages/disadvantages, and the second method creates an object which has no prototype (You: wait, what now? Me: keep patience, this is only part one).

Once the object has been created, there are four ways we can create properties for the object -

/* 1. The dot notation
 */
obj.firstProperty = 'this is a property';    // set property
var value = obj.firstProperty;    // get property
console.log(value);

/* 2. Square bracket notation
 */
anotherObj['key'] = 24;    // set property
var result = anotherObj['key'] + 6;    // get property
console.log(result);

/* 3. With Object.defineProperty. ECMAScript 5+ only.
 */
// Set property
Object.defineProperty(lastObj, 'key', {
    value: 'this is key value',
    writable: true,
    enumerable: true,
    configurable: true
});

// get property - use any of the method described in 1 or 2
console.log(lastObj.key);

/* 4. With Object.defineProperties. ECMAScript 5+ only.
 */
// Set property
Object.defineProperties(obj, {
    'secondKey': {
        value: 'I am second',
        writable: true
    },
    'thirdKey': {
        value: 'I am third',
        writable: false
    }
});

// get property - use any of the method described in 1 or 2
console.log(obj.thirdKey);

Method 1 and 2 are almost same, except that if a property name is not a valid identifier (you know, names starting with letters, or names not containing valid characters etc.), then method 1 will generate an error, while method 2 won’t. You can also use a variable inside a square bracket, whose value will first be substituted there, and then be converted to string, and then be used as a key!

Method 3 provides much more flexibility than method 1 and 2 over the property creation.

How?

Besides creating properties and setting their values, these methods also allow us to input property configuration! Each JavaScript property has a property descriptor consisting some attributes/properties which describes their characteristics -

1. writable: Can we change the value of this property after it has been created using the assignment operator? This attribute answers this question. If it’s set to true, value of a property can be changed once it’s created. If it’s set to false, we won’t be able to change the value once the property has been created. This gives rise to immutable properties in JavaScript.
2. enumerable: Can we enumerate/traverse this property using the in (You: again, wait. What’s this?! Me: again I am saying, this in only first part, dam’it) operator (or, in some other similar way)? This attribute answers this question. If set to true, we will be able to enumerate this property using the in operator, otherwise we can’t.
3. configurable: Can we delete this property or change it’s property descriptor after it’s been created? This attribute answers this question. If set to true, we can delete this property from the object using the delete operator (see below) or change it’s descriptor (use defineProperty again with different configuration value). Otherwise, we can’t.

Note: Even after setting configurable to false, you can still change the writable configuration from true to false. This is the only exception. The reason behind this is described here pretty nicely.

You can define a variable (beware of polluting the global namespace!!) and a function for your convenience to create object properties in this way -

var config = {
    writable: true,
    enumerable: true,
    configurable: true
};

function defineProperty(object, key, value) {
    config.value = value;
    Object.defineProperty(object, key, config);
}

var myObject = {};
defineProperty(myObject, 'first', 'hello');

config.writable = false;
defineProperty(myObject, 'second', ' world');

Method 4 is just a variation of 3 which enables us to define more than one properties at the same time.

Play with these as long as you want. You may use Firebug as your playground.

Deleting properties

You can delete an object property using the delete operator -

var myObject = {};
myObject.key = 'value';

console.log(myObject.key);    // will print "value" on console

delete myObject.key;

console.log(myObject.key);    // will print "undefined"

That’s it for today. I’ll try to write the second post as soon as I can. Any comments – suggestions, corrections, modifications – are welcome!

Acknowledgements

1. Addy Osmani: Learning JavaScript Design Patterns
2. Yehuda Katz: Understanding Prototypes in JavaScript
3. Juriy Zaytsev: ECMAScript 5 compatibility table

An introduction to Design Pattern – Part 3

Prerequisite

Before reading this article, you should read the first and second part of this series.

Delegation

When a client object X requests some service from an object Y, then Y may decide to pass this request to another object Z instead of handling the request by itself. When this happens, we say that receiver object Y has delegated its operation to its delegate Z. This process is known as delegation and it’s a way of making object composition as powerful for reuse as inheritance.

Let us now consider an example from this famous book on design patterns. Suppose that we want to create a class which will generate a window.  The code for this class may look something like below -

/* We are using an interface so that all window drawing classes have a
 * common Object Interface (Remember the OOP principle 1 from first part? ) 
 */
public class Window
{
    // Various member variables
    public void drawWindow()
    {
        // Code to draw the window
    }

    // various other methods
}

This approach is a naive one. A better approach would be to create a Rectangle class which will contain the logic to generate a simple rectangle and then inherit this Window class from this rectangle and thereby including its functionality.

However, there is another approach. Instead of inheriting this Window class from Rectangle, we may delegate the responsibility from this class to another class called DrawRectangleShape like this -

public interface DrawWindow 
{
    public void draw(Window X);
}

public class DrawRectangleShape implements DrawWindow
{
    // various data and methods

    public void draw(Window X)
    {
        // logic to generate a rectangular-shaped window X
    }
}

public class Window
{
    DrawWindow windowDrawer;
    // Various member variables

    public Window()
    {
        /* It is OK to initialize this windowDrawer reference to a particular
         * object instance, but you should also provide setter method so that
         * this reference can be changed dynamically.
         */
        this.windowDrawer = new DrawRectangleShape();
    }

    public void setWindowDrawer(IDrawWindow windowDrawer)
    {
        this.windowDrawer = windowDrawer;
    }

    public void draw()
    {
        this.windowDrawer.draw(this)        // Pass self-reference to the delegate
    }

    public void redraw()
    {
        // destroys the current window, then regenerates it
    }

    // various other methods
}

Now if you look at the code you’ll see that the Window object is passing itself to the delegate so that the delegate can properly generate a rectangular window. This is always the case when the delegate requires a reference to the receiver.

Now why should we use delegation?

The main advantage of delegation is that it makes it easy to compose behaviors at run-time. Consider another implementation of the IDrawWindow interface -

public class DrawCircularShape implements DrawWindow
{
    // various data and methods

    public void draw(Window X)
    {
        // logic to generate a circular-shaped window X
    }
}

Now consider the following piece of code -

Window newWindow = new Window();
newWindow.draw();

DrawWindow newWindowDrawer = new DrawCircularShape();
newWindow.setWindowDrawer(newWindowDrawer);
newWindow.redraw();

The above piece of code first generates a rectangular-shaped window. After that, it replaces its default rectangular shape drawer with a circular shape drawer and then redraws itself. As a result, the window will become circular from rectangular at run-time!!!

So, using delegation you can change the behaviors of objects at run-time in this way. A lots of design patterns make use of this technique.

Unfortunately, delegation has some disadvantages too. Dynamic, highly parameterized software is typically harder to understand than more static software. If you delegation then you will have codes that changes behaviors at run-time. Understanding these varying behaviors may prove to be difficult. There are also some run-time inefficiency since you have to create new objects and transfer responsibilities to them, but this is negligible because most of the modern processors are pretty fast and because of the flexibility it brings to a software design.

So when using delegation, always make sure that it simplifies the design more than it complicates. Only then you will be able to leverage the true power of delegation.

Conclusion

At this point you should have a pretty good understanding of what design patterns are and what do they accomplish. You will find various other definitions on various books and on the web. I think you will now understand all of them . Read them on your own. For the time being, I am going to include the definition of design patterns given by Christopher Alexander who first introduced the idea -

The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

I hope someone finds this series useful .

An introduction to Design Pattern – Part 2

Prerequisites

Before reading this article, you should read the first part of this series. In the following article, I may have used class and object interchangeably. Unless otherwise stated, they both mean the same thing.

Abstract Class VS Concrete Class

An abstract class is one which is generally declared using the keyword abstract and which has at least one method which doesn’t have a definition (or a body/implementation, whatever you say). Classes which aren’t declared using the abstract keyword is called Concrete Classes.

All the classes that I have given example of in the previous article are concrete classes.

Let us see an example of an abstract class -

public abstract class AnAbstractClass{
    protected string anAttribute;

    public void setAttribute(strint anAttribute){
        this.anAttribute = anAttribute;
    } 

    public string getAttribute(){
        return this.anAttribute;
    }

    public void anAbstractOperation();
}

The above class is an abstract class, since it is declared as abstract in its class definition. Abstract classes will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn’t implement are called Abstract Operations.

Now, why do we care ?

We do care about abstract classes because they play an important part in design patterns. An abstract class is one whose main purpose is to define a common interface for its subclasses (“subclass” will be explained shortly). They are generally used to define a Base Type to be used in the class hierarchy of a system.

Inheritance

In OOP, new classes can be defined in terms of existing classes. This mechanism is known as inheritance. When a new class is created in this way, we say that it is a subclass of the existing class from which it is  being inherited, and the existing class is called its parent class.

In the previous article of this series (link of which is given in the prerequisite section), I have shown an example of inheritance. Feel free to take a look at that example.

Objects that are instances of the subclass can contain all data defined by the subclass and its parent classes, and they’ll be able to perform all operations defined by this subclass and its parents.

But again, those who want to see another example, consider the following one -

// Example 1
public class Account{
    protected string accountNumber;
    protected double balance;

    public Account(){}

    public void setAccountNumber(string accountNumber){
        this.accountNumber = accountNumber;
    }

    public string getAccountNumber(){
        return this.accountNumber;
    }
}

public class InventoryAccount extends Account{
    protected string inventoryItemNumber;

    public InventoryAccount(){}

    public void setItemNumber(string itemNumber){
        this.inventoryItemNumber = itemNumber;
    }

    public string getItemNumber(){
        return this.inventoryItemNumber;
    }
}

In this example, we are creating a new class called InventoryAccount by inheriting it from Account class. As a result, all of the operations that Account class defines will be available in the InventoryAccount class. Here, InventoryAccount is a subclass of Account class, and Account class is a superclass of InventoryAccount.

Class Inheritance VS Interface Inheritance

“What the heck!? There are two types of inheritance?!”

Yes, that’s right. We use both of them on a daily basis, we just aren’t aware of the distinction. Class inheritance defines an object’s implementation in terms of another object’s implementation. In short, it’s simply a mechanism for code and representation sharing. The example that I’ve provided just above is an example of this type of inheritance.

Interface inheritance, sometimes known as subtyping, ensures that an object has a specific type of object interface which it obtains either from a programming language’s interface (let’s call it method interface just to distinguish itself from the Object Interface for now) or from an object.

“Huh? What did you just say? Aren’t both of these are the same thing then ?”

Nope, they are not. Look at the example I have provided. Here, InventoryAccountis inherited from Account class. So it also inherits both the methods that Account class provides, along with their implementation. This is an example of class inheritance – InventoryAccount is defined in terms of Account class’s implementation (along with its other methods, of course).

But, if I inherit InventoryAccount in the following way -

public class InventoryAccount extends Account{
    protected string inventoryItemNumber;

    public InventoryAccount(){}

    public void setAccountNumber(string accountNumber){        // Overriding Account's implementation
        this.accountNumber = accountNumber;
    }

    public string getAccountNumber(){                         // Overriding Account's implementation
        return this.accountNumber;
    }

    public void setItemNumber(string itemNumber){
        this.inventoryItemNumber = itemNumber;
    }

    public string getItemNumber(){
        return this.inventoryItemNumber;
    }
}

then I am only inheriting Account’s Object Interface, not their implementation. This is called interface inheritance.

Still not clear? Then comment back in!

Class inheritance is basically just a mechanism for extending an application’s functionality by reusing functionality in parent classes. It lets you define a new kind of object rapidly in terms of an old one. It lets you get new implementations almost for free, inhering most of what you need from existing classes. However, implementation reuse is only half the story. Inheritance’s ability to define families of objects with identical interfaces is also important.

Why? Because Dynamic Binding, and in turn, Polymorphism depends on it (“Huh? How?”).

When inheritance is used carefully (some will say properly), all classes derived from an abstract class will share its interface. This implies that a subclass merely adds or overrides operations and does not hide operations of the parent class. Consequently, all subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class. As a result, all of these subclasses can be switched with one another in run-time, resulting in polymorphic behaviors.

There are two major benefits to manipulating objects solely in terms of the interface defined by abstract classes –

• Clients (take a look at the definition of “client” from the previous article) remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.

• Clients remain unaware of the classes that implement these objects. Clients only know about the abstract classes defining the interface.

Can you imagine the implication of the above two points ? You can’t ? Ok, fine, then let me help you.

Consider our Accounting example. Suppose that you are developing an accounting application which only handles Inventory Accounts and you have created only InventoryAccount class. Your code looks somewhat like below -

List<InventoryAccount> accounts = new ArrayList<InventoryAccount>();
accounts.Add(new InventoryAccount("Whatever initialization parameter is needed"));

.............. // Add another thousand class, do some manipulation, then save
ClassThatSavesAnAccountListToTheDatabase newClass = new ClassThatSavesAnAccountListToTheDatabase();
newClass.save(accounts);

Now after working hard for 3-4 months, your client (this client is a person ) comes to you and tells you, “Sooo sorry, I forgot to mention that this software will also manage our salary accounts. Could you do that for us, it would be a great help “, at that very moment you will be thinking, “Darn it, I am dead “.

Why?

Because to accommodate this change, you will have to declare a new account class called SalaryAccount, code for its business logic, persistence etc. You will also need to change the business logic in every place of your system, re-test it again thoroughly, and be sure that there will be hundreds of bugs this time in your system, all of which will be needed to be taken care of by you. In this scenario, we say that there is an implementation dependency between the subsystems of your application.

Instead of developing this way, if you would have declared an abstract class called Account and inherited InventoryAccount like the way I have shown in the inheritance example, and coded your application like this -

List<Account> accounts = new ArrayList<Account>();
accounts.Add(new InventoryAccount("Whatever initialization parameter is needed"));

.............. // Add another thousand class, do some manipulation, then save
ClassThatSavesAnAccountListToTheDatabase newClass = new ClassThatSavesAnAccountListToTheDatabase();
newClass.save(accounts);

then you could have just declared another class called SalaryAccount by extending your Account abstract class and it would have fitted nicely with your existing code. You will still need to change some part of your code, but believe me, the amount of change will be very, very less in this later case, and we say that implementation dependency in this case is kept to minimal.

So the problem arose because you have coded your application using a reference to a concrete type, rather than using am abstract type. All the clients of your InventoryAccount class were aware of this fact, and hence fitting in the new class proved to be difficult.

So, I hope now you can realize the benefits to manipulating objects solely in terms of the interface defined by abstract classes. This way of coding so greatly reduces implementation dependency between subsystems that it leads to the following principle of Reusable Object-Oriented design -

OOP Principle 1: Program to an Interface, not to an Concrete Implementation

What does this mean?  In short, this principle says that you should not declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class or method interface.

Does design pattern help us to achieve this principle

What do you know, it does! Almost all of the design patterns make use of this principle and show you a way to use it in your application. So, we can say -

Design patterns help us to program to an interface, not to an concrete implementation, thereby reducing
implementation dependency as much as possible.

There you go. Another definition of what design patterns are .

Reuse Mechanism in OOP

There are a lot of ways we can reuse existing code in an application, but the following two mechanisms are mostly used -

• Class Inheritance

• Object Composition

As we have learned before, class inheritance lets us define new implementation of one class in terms on another’s. Reuse by Subclassing in this way is often referred to as White-box reuse, because with this type of inheritance, the internals of parent classes are often visible to subclasses. Class inheritance is defined statically at compile-time and is straightforward to use, since it is supported directly by most of the OO languages. Class inheritance also makes it easier to modify the implementation being reused. When a subclass overrides some but not all of the operations, it can affect the operations it inherits as well, assuming the call the overridden operations.

But this type of reuse mechanism has some serious limitations. First, you cannot change the implementations inherited from parent classes at run-time, because inheritance is defined at compile-time, resulting in causing difficulties for polymorphism. Second, parent classes often define at least part of their subclasses’ physical representation. Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that Inheritance Breaks Encapsulation.

“What?! Did I hear you right?!”

Yes, you did. It may sound scary, but it’s true, because in this case the implementation of a subclass becomes so bound up with the implementation of its parent class that any change in the parent’s implementation will force the subclass to change. This is another form of Implementation Dependency.

Consider the following example -

public class Display{
    private string dataToDisplay;

    public Display(){}

    private void setDisplayData(string dataToDisplay){
        this.dataToDisplay = dataToDisplay
    }

    private string getDisplayData(){
        return this.dataToDisplay;
    }

    public void displayDataVertically(){
        // Code to display the data vertically
        .......
    }
}

public class LCDDisplay{

    public LCDDisplay(){}

    public void displayDataHorizontally(){
        // Code to display data horizontally
    }
}

In the above example, LCDDisplay is inheriting the displayDataVertically operation from its parent class, Display. If I change the logic of this operation in the Display class, it will also force the behavior of the LCDDisplay class to change, because this functionality of LCDDisplay class is defined in terms of the implementation that the Display class provides, resulting in the implementation dependency, and if the height of this inheritance tree keeps growing, you will really be in trouble if you ever need to change even a small part of your application.

This type of implementation dependencies can cause problems when you’re trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability. One cure for this is to inherit from abstract classes, since they usually provide little or no implementation.

Object composition is an alternative to class inheritance. Here, new functionalities is obtained by assembling or composing objects to get more complex functionality. It requires that the objects being composed have well-defined object interfaces. This style of reuse is called Black-box reuse, because no internal details of objects are visible. Objects appear only as black boxes.

Let us look at the following example -

public class Account{
    protected string accountNumber;
    protected double balance;
    protected InterestRateCalculatorInterface RateCalculator;
    protected final double rate = 0.5;                        // Bad coding style, please don't follow it.
                                                              // I am using it just for the sake of this
                                                              // example.

    public Account(double initialBalance){
        this.balance = initialBalance;
    }

    public void setBalance(double initialBalance){
        this.balance = initialBalance;
    }

    public double getBalance(){
        return this.balance;
    }
    public void setAccountNumber(string accountNumber){
        this.accountNumber = accountNumber;
    }

    public string getAccountNumber(){
        return this.accountNumber;
    }

    public void setRateCalculator(InterestRateCalculatorInterface RateCalculator){
        this.RateCalculator= RateCalculator;
    } 

    public InterestRateCalculatorInterface getRateCalculator(){
        return this.RateCalculator;
    }

    public void calculateRateAndUpdateBalance(int numDays)
    {
        this.balance = this.RateCalculator.returnInterestRate(this.balance, numDays, this.rate);
    }
}

public interface InterestRateCalculatorInterface{               // Now that's what we've named method interface
                                                                // this series of articles.

    public double returnInterestRate(double baseValue, int numDays, int rate);
}

public class InterestCalculator implements InterestRateCalculatorInterface{
    public double returnInterestRate(double baseValue, int numDays, double rate){
        double finalRate = (double) ( baseValue + (baseValue * numDays * rate) );

        return finalRate;
    }
}

class SomeCertainClass{
    public static  void main(String[] args){
        Account newAccount = new Account(0.0);
        InterestRateCalculatorInterface RateCalculator = new InterestCalculator();    // Remember our
                                                                                  // OOP Principle 1?
        newAccount.setRateCalculator(RateCalculator);

        newAccount.calculateRateAndUpdateBalance(30);
        System.out.Print("The new balance is: " + newAccount.getBalance());
    }
}

In the above example, we are assigning an instance of an InterestCalculator object, which has the type InterestRateCalculator,  to the member variable of the Account object at run-time, which adds a new functionality in the Account class and enables it to calculate interest rate and update the current balance. This is an example of object composition, and we say that the Account object is being composed by an object which has the type InterestRateCalculatorInterface at run-time.

Object composition is defined dynamically at run-time through objects acquiring references to other objects, thus being more Polymorphism-friendly. It requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a pay-off. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects ( if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class.

From the above discussion, we can see that object composition has very, very few bad effects compared to the class inheritance. This gives rise to our second OOP Principle -

OOP Principle 2 - Favor Object Composition over Class Inheritance

Ideally, Ideally, you shouldn’t have to create new components to achieve reuse. You should be able to get all the functionalities you need just by assembling existing components through object composition. But this is rarely the case, because the set of available components is never quite rich enough in practice. Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together. Nevertheless, statistics say that designers overuse inheritance as a reuse technique, and designs are made more reusable and simpler by depending more on object composition.

Does design pattern help us to achieve OOP Principle 2

Yes it does. There is a pattern called strategy which teaches us how to compose objects at run-time to get different behaviors out of a particular class. Almost all of the design patterns favor composition over inheritance. So, we can say -

Design patterns enable us to reuse our code in the most efficient way by favoring object composition
over class inheritance.

Enough for today. I am tired and hungry. I hope I can finish this introduction in the next article. Until then, good bye .

An introduction to Design Pattern – Part 1

Prerequisite

It will be better if you have a rough understanding of object oriented programming and its concepts like encapsulation, polymorphism and inheritance. If you don’t have those then this article may appear a little confusing. If it does then comment back in, I will try my best to explain. All of the example code that I provide here will follow Java syntax.

What are design patterns

From wikipedia –

A design pattern in architecture and computer science is a formal way of documenting a solution to
a design problem in a particular field of expertise.

What do you understand from the above two lines ?

If you ask me, I will say – not a darn thing. This is the problem that occurs to all the beginners in design patterns. People and websites who teach these stuff seem to talk in a way that is very hard for the beginners to understand. Rather than pursuing these heavy definitions, let us learn what design patterns are by looking at their applications.

Do you know what are Objects

To simply put, an object is something that has -

• data (or, you can say attributes/properties/states)
• operations that operate on the data (they are also called methods)

Objects are used to perform some operations using their data. An object performs an operation when it receives a request from another object. The requesting object is said to be a client of the first object. You request an operation of an object by invoking one of its methods with appropriate arguments. In return, that operation performs some job for you and may return you a response.

Enough talk. Let’s see some code.

Before you create an object, you need to let the compiler know what data and operations will that object contain. You do this by declaring a class as follows -

public class Person{
    protected String name;    // Data

    public  person(){}    // Constructors, a special type of operation

    public String getName(){     // Operation
        return this.name;
    }

    public void setName(String name){
        /** 
         * Here EscapeString is another object whose
         * service is being requested by this Person
         * class. So Person is a client of EscapeString.
         */
        String escapedName = EscapeString.escape(name);
        this.name = escapedName;
    }
}

You can think of the class as a blue print for compilers which describes what data and operations will an object contain in it.

And now, to create an object, you use the following syntax -

Person aPerson = new Person();

Again I would like to point out that this article is not for those who are absolute beginner in object oriented programming . This article provides a different perspective of those concepts. You should acquire basic concepts from this fine article that Java’s official site provides.

Requests are the only way to get an object to execute an operation. Operations are the only way to change an object’s internal data. Because of these restrictions, the object’s internal state is said to be encapsulated.

Meet Encapsulation

Encapsulation means that the data that an object contains cannot be accessed directly from outside that object, and its representation is invisible from outside the object. It is a great way to develop a loosely coupled software components.

What the heck do the above two lines mean ?

It means that you cannot access the name property of the Person object directly. If you need to get that value then you will have to request it through the getName method. Doing it this way gives the designer of the object a lot of flexibility, i.e., he can change the name of the variable to myname and it still won’t cause any code to change outside this object. The designer can even choose to store the name value in a Java Map or in an array without much trouble.

Does design patten help us to maintain encapsulation

Yes, it does! There are a lots of design patterns that are targeted specifically for this purpose. One of them is Strategy Pattern. It helps us to encapsulate complex data structures, algorithms, changing behaviors into their own separate class and protect the rest of the system from any change that may occur in them. So, we can say -

Design patterns help us to maintain Encapsulation when we write an application in a true object oriented way

This is one of the most important uses of design patterns.

How should we determine what should be an object

• You can write a problem statement, single out the nouns and verbs, and create corresponding classes and operations.
• Or you can focus on the collaborations and responsibilities in your system.
• Or you can model the real world and translate the objects found during analysis into design.

Do you understand anything from the above three points ?

If you don’t, then don’t worry. These are part of a broader topic known as system analysis and design, which I will cover later in the future.

What you would like to know whether or not design patterns help you to determine what should be an object in your system, and you will be glad to know that they do. There is a pattern called Facade which describes how to represent subsystems as objects. There is also another pattern known as Flyweight that describes how to support huge number of objects at the finest granularities.

So we can say -

Design patterns help us to decide what should be an object in our system.

This is another important use of design patterns.

Method signature, Object Interface, Types, Subtypes and Supertypes

Every operation declared by an object specifies the operation’s name, the objects it takes as parameters, and the operation’s return value. This is know as the operation’s signature. Don’t confuse it with method signature which doesn’t include the return type of a method.

Let us consider the Person object discussed earlier. The method signature of its getname operation is -

String getName()

The set of all signatures defined by an object’s operations is called the interface to the object (beware people, it’s not the same as our programming language’s interface  construct). There is one thing that you should be aware of. Some OOP languages allow us to declare methods that cannot be accessed from outside that object (i.e., in java using private, protected keywords). Those methods won’t be included in the object interface since you cannot request those operations to an object from outside that object.

If we consider the Person object, then its interface is -

{void setName(String name), String getName()}

An object’s interface characterizes the complete set of requests that can be sent to the object. Any request that matches a signature in the object’s interface may be sent to the object.

A type is a name used to denote a particular interface. We speak of an object as having the type X if it accepts all requests for the operations defined in the interface X. An object may have many types, and widely different objects can share a type.

As an example, we can say that the interface that our Person object defines is of type Person.

Interfaces can contain other interfaces as subsets. We say that a type is a subtype of another if its interface contains the interface of its supertype.

Let us consider an example. Suppose that I have a class called Man whose interface is as follows -

{void setName(String name), String getName(), void playCricket(), void playKabadi()}

This object’s interface contains all the method signatures that are defined in the Person object’s interface. So in this case we can say that Man is a subtype of Person, and Person is a supertype of Man. We can also say that this Man object’s interface inherits the Person’s object’s interface.

Why am I talking about these stuff?

Because interfaces are fundamental in object-oriented systems. Objects are known only through their interfaces. There is no way to know anything about an object or to ask it to do anything without going through its interface. An object’s interface says nothing about its implementation though. Different objects are free to implement requests differently. That means two objects having completely different implementations can have identical interfaces.

Let me clarify the last point with an example. Consider the following definition of the Man object -

public class Man extends Person{

    public Man(){}

    public String getName(){
        return EscapeString.escape(this.name);
    }
    public void setName(String name){
        this.name = name;
    }
    public void playCricket(){
        System.out.Print("I am playing cricket");
    }
    public void playKabadi(){
        System.out.Print("I am playing kabadi");
    }
 }

This example uses inheritance to make sure that the Man object has the Person object’s interface as its subtype. You can learn more about inheritance by reading the Sun Java’s article. All I will say is this – since we are inheriting Man class from Person class, then all of the methods that constitute its object interface will also be included in the Man class. The Man class is providing a different implementation to those methods by overriding definition/implementation of those methods. That’s all we care about for this article.

Those who find this example confusing, I would like to say to them that Object Interface and Java/C# language’s interface aren’t the same thing, though they have so much in common. Object interface is the collection of all signatures of all the methods that can be called from outside that object; where as an interface in C#/Java defines a collection of method signatures that some object can implement, thus including those signatures in its Object Interface. In this sense you can say that an interface construct in C#/Java defines an object interface, but it isn’t the only way. In those languages we can ensure that an object has a specific Object Interface by one of two ways -

• By extending/inheriting another from another object. In this way the object’s Object Interface from which it is being inherited will be included in this object.
• By declaring an interface, which is a collection of method signature, using the interface keyword that those languages provide and implementing that interface.

Probably now you will want to say that aren’t these two are the same thing? I will say, no, because an object that doesn’t implement any Programming Language’s interface still has an Object Interface, which is the collection of all the signatures of all those methods that can be called outside from this object.

Please think about this distinction thoroughly before moving on.

From our definition of interface, type and subtype, we can say that Man class also has Person as its type, because it accepts all the operations defined in the Person interface type.  It’s supertype is Person, and it’s a subtype of Person.

Now, look at the implementation of the getName and setName. They are completely different from the Person’s implementation, although they have common interface.

Since these objects have common interface, you can use one in place of another when you’re dealing with only that common interface. Let me clarify it with another example. Consider the following method of a certain class -

public String returnProcessedName(Person p)
{
    /** 
     * nameProcessor is a member variable of CertainClass
     * whose type is <em>Person</em>. You can use a setter
     * method for setting up appropriate name processor,
     * but hey, this is just an example!
     */
    this.nameProcessor = p;
    return this.nameProcessor.getName();
}

Now I can call this method like this -

Person newPerson = new Person();
CertainClass c = new CertainClass();

newPerson.setName("Stupid");
String processedName = c.returnProcessedName(newPerson);

Or like this -

Man newMan = new Man();
CertainClass c = new CertainClass();

newMan.setName("Stupid");
String processedName = c.returnProcessedName(newMan);

This code snippet is also valid. Why? Because both the Person and the Man object has a common interface, which we have named Person before. So you can use one object in place of another whenever you are dealing with that interface. If you pass a Person object’s reference to the returnProcessedName method, then it will call the getName implementation that this class or object provides. Similarly, if you pass a Man object’s reference then its implementation will be called. Hence we can say that which implementation of getName will be called will be determined at runtime, which means when the application runs, rather than at compile time, which means when the application is compiled. This runtime association of a request to one of its implementation is known as Dynamic Binding.

Dynamic binding means that issuing a request doesn’t commit you to a particular implementation until run-time. Consequently, you can write programs that expect an object with a particular interface, knowing that any object that has the correct interface will accept the request.

This property is very, very important because Polymorphism depends on it.

So, we have stumbled upon Polymorphism

Dynamic binding lets you substitute objects that have an identical interfaces for each other at run-time. This substitutability is known as polymorphism. It lets a client object make few assumptions about other objects beyond supporting a particular interface. As a result, it simplifies the definition of clients, decouples objects from each other and lets them vary their relationships to each other at run-time. These inter-changeable classes are said to display polymorphic behaviors.

Let us discuss this with respect to the last example.

In our last example, the CertainClass is a client of the Person interface. Since both the Person object and Man object have this interface, we have been able to use both of these objects in the CertainClass. The client class doesn’t even have to know which implementation it is being provided as long as the implementation or object has this Person interface. This is the true meaning of polymorphism, and this client object CertainClass is said to display polymorphic behavior because at run-time it can achieve one of two different behaviors by simply switching between the instances of the Person and Man class like this -

Person newPerson = new Person();
CertainClass c = new CertainClass();

newPerson.setName("Stupid");
String processedName = c.returnProcessedName(newPerson);
System.out.println("Current name: " + processedName);

Man newMan = new Man();
newMan.setName("Stupid");

/**
 * Now you will get name processed in a different
 * way, because implementation is different!
 */
processedName = c.returnProcessedName(newMan);
System.out.println("Current name: " + processedName);

This greatly reduces the complexity of accommodating changes in our application because if you design an application using polymorphism then you can plug in any implementation of this interface in your application without having to test and re-test your application and without breaking any of the existing code.

Does design pattern help us achieve polymorphism ?

Yes, it does! So we have found another use of design pattern -

Design pattern lets us design a flexible application by helping us maintaining true polymorphism in our
application

This is so far I am going to go in this article. I will soon write the second part of this article. Until then, enjoy .

Just another developer blog

In this blog I will be writing about various stuff that I encounter in my career as a software developer. Sometimes it will be about languages, sometimes about designs and architectures.

Hope somebody somewhere in the world find this blog useful.