Chapter 10: Implementing an Interface

We have been using references to the term “Implementing an Interface” throughout the preceding chapters and we havent yet actually dug deep into this topic. As you might remember, an Interface is nothing but a contract as to how a class should behave. It just declares the behavior as empty methods and the implementing class actually writes the code that will determine the behavior.

When you implement an interface, you’re agreeing to adhere to the contract defined in the interface. That means you’re agreeing to provide legal implementations for every method defined in the interface, and that anyone who knows what the interface methods look like can rest assured that they can invoke those methods on an instance of your implementing class. (Thy need not bother much about how you have implemented it. All they bother about is whether a method of the name mentioned in the interface is available or not)

Now, you might stop me and ask, what if I implement an interface and opt not to write code for a method that I am supposed to? The answer is simple. The compiler wouldn't let you do that. You cannot successfully implement an interface without providing method implementation for all the methods declared inside the interface. This is how the java system ensures that when someone knows a certain method name in an interface and has an instance of a class that implements it, can actually call that method without fear that the method isnt implemented inside the class.
Assuming an interface, Convertible, with two methods: openHood(), and setOpenHoodFactor(), the following class will compile:

public class Ball implements Convertible { // Keyword 'implements'
public void openHood() { }
public void setOpenHoodFactor(int bf) { }
}

Ok, I know what you are thinking now. “This has got to be the worst implementation class that you have seen”. Though it compiles and runs as well, it is actually doing nothing… the interface contract guarantees that the class implementing it will have a method of a particular name but it never guaranteed a good implementation. In other words, the compiler does not bother whether you have code inside your method or not. All it cares is if you have methods of the matching names as in the interface. That's all…

Implementation classes must adhere to the same rules for method implementation as a class extending an abstract class. In order to be a legal implementation class, a nonabstract implementation class must do the following:
• Provide concrete (nonabstract) implementations for all methods from the declared interface.
• Follow all the rules for legal overrides.
• Declare no checked exceptions on implementation methods other than those declared by the interface method, or subclasses of those declared by the interface method.
• Maintain the signature of the interface method, and maintain the same return type (or a subtype).
• It does not have to declare the exceptions declared in the interface method declaration.

Tip: What if an implementing class does not want to provide implementation for all methods? Can we make that class compile? Of course yes, just make the class abstract. This means that the compiler wont check if all the methods are implemented.
Ex:
abstract class SuperCar implements Convertible { }

Notice anything missing? We never provided the implementation methods. And that’s OK. If the implementation class is abstract, it can simply pass the buck to its first concrete subclass.
You can have a class like:
Public class SuperSuperCar extends SuperCar {
public void openHood() {
System.out.println(“Opening the Hood”);
}
public void setOpenHoodFactor(int bf) {
System.out.println(“Opening the hood at speed: “ + bf);
}
}
This class SuperSuperCar is the first concrete (or non-abstract) class that extends the SuperCar class and actually provides the implementation for the methods in the interface Convertible that the SuperCar class implements.

Exam Tip: You may have questions wherein a class implements an interface but does not provide all the method implementations (check for method signatures too) Unless the implementing class is abstract, the implementing class must provide implementations for all the methods defined in the interface. You should be careful to spot such instances and answer them appropriately.

There are two more rules you need to know before we can wrap up this chapter:
1. A class can implement more than one interface. It’s perfectly legal to say, for example, the following:
public class Car implements Convertible, Serializable, Runnable
{ ... }

You can extend only one class, but implement many interfaces. But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree).

2. An interface can itself extend another interface, but never implement anything. The following code is perfectly legal:

public interface Convertible extends Moveable { } // ok!

What does that mean? The first concrete (nonabstract) implementation class of Convertible must implement all the methods of Convertible, plus all the methods of Moveable! The subinterface, as we call it, simply adds more requirements to the contract of the superinterface. You’ll see this concept applied in many areas of Java, especially J2EE where you’ll often have to build your own interface that extends one of the J2EE interfaces.

i.e., public class A extends B, C {…} is illegal whereas
public Interface A extends B, C {…} is perfectly legal

Exam Tip: Watch out for legal/illegal usage of extends and implements. There might be quite a few questions on this.
1. class Car {} - No Problems
2. class Ferrari Implements Car {} – Not Ok. Car is a class not an Interface
3. interface Convertible {} – No problems
4. interface Moveable {} – No problems
5. interface CarTop implements Convertible {} – Not Ok. An Interface cannot implement another interface
6. interface CarTop implements Car {} – Not Ok. An Interface cannot implement a class
7. interface CarTop extends Car {} – Not Ok. An Interface cannot extend a class
8. interface CarTop extends Convertible {} - No Problems. An Interface can extend another Interface
9. class Ferrari extends Car, Automobile – Not Ok. A Class cannot extend multiple classes
10. class Ferrari implements Convertible, Moveable {} – No Problems. A Class can implement multiple interfaces
11. class Ferrari extends Car implements Convertible {} – No Problems. A Class can both extend a class and implement an interface
12. class Ferrari implements Convertible extends Car {} - Not Ok. The extends should come first.

Burn these in, and watch for incorrect usage in the questions you get on the exam. Regardless of what the question appears to be testing, the real problem might be the class or interface declaration. Before you get caught up in, lets say, tracing a complex threading flow, check to see if the code will even compile first. (You’ll be really impressed by the effort the exam developers put into distracting you from the real problem.) You take the bait, you choose a wrong answer that would look perfectly legitimate while the code won’t compile in the first place.

Previous Chapter: Chapter 9: Reference Variable Casting

Next Chapter: Chapter 11 - Legal Return Types

Chapter 2: Declarations

Classes and Interfaces are the basis based on which the java programming universe revolves. Everything in Java is an object but an object is nothing but the runtime orientation of a class. In other words, an object is nothing but a class that is being executed.

Whenever you write any java code, it implicitly means that you are writing classes or interfaces. Within those classes, as you know, are variables and methods (plus a few other things). How you declare your classes, methods, and variables dramatically affects your code’s behavior

Source File Declaration Rules:

Before we dig into class declarations, let’s do a quick review of the rules associated with declaring classes, import statements, and package statements in a source file:
• There can be only one public class per source file.
• Comments can appear at the beginning or end of any line in the source code file; they are independent of any of the positioning rules discussed here.
• If there is a public class in a file, the name of the file must match the name of the public class. For example, a class declared as public class Rock { } must be in a source code file named Rock.java.
• If the class is part of a package, the package statement must be the first line in the source code file, before any import statements that may be present.
• If there are import statements, they must go between the package statement (if there is one) and the class declaration. If there isn’t a package statement, then the import statement(s) must be the first line(s) in the source code file. If there are no package or import statements, the class declaration must be the first line in the source code file.
• import and package statements apply to all classes within a source code file. In other words, there’s no way to declare multiple classes in a file and have them in different packages, or use different imports.
• A file can have more than one nonpublic class.
• Files with no public classes can have a name that does not match any of the classes in the file.

Now that we have taken a look at the rules for declaring a java source code file, let us get into the real thing about declaring classes.

Declaring Classes:

A Class can be declared with the following statement:

public class AnandsFirstclass {}

Irrespective of the fact that this class does not have any code, this piece of code when saved in a file called AnandsFirstclass.java compiles just fine. Here public is an access modifier (we will see access modifiers in greater detail in one of the subsequent chapters), class is the keyword that is used to specify that a class is being declared and AnandsFirstclass is the name of the class we are creating.

There are many different types of classes that you can create. Some of which are:
1. Final Classes – A class that cannot be inherited (Dont worry about inheritance just yet. We will look into it in full detail in one of the later chapters)
2. Normal Classes – The type of class that we declared a few lines back
3. Abstract Classes – A class that is similar to a normal class but that does not provide full functional behaviour by itself. It has to be subclassed/inherited in order to be used.

Abstract Classes in Detail:
An Abstract class is a special kind of class that cannot be instantiated. It has one or more methods which are not implemented in the class. These methods are declared abstract and they do not contain any code inside them.

Ex:
abstract class Parent {
public abstract String getSon();
public abstract String getDaughter();
....
....
//More methods that contain specific behaviour/code in them
}

The above is an abstract class “Parent” that has a lot of functionality but it has declared two abstract methods which have no code inside them. Any class that has one or more abstract methods has to be abstract. This abstract class cannot be instantiated.

i.e., the below piece of code will not work. The code will not even compile.

Parent object = new Parent();

Purpose of Abstract Classes:
Abstract classes are generally used where you want an amount of behaviour to be used by the class that extends the abstract class while at the same time giving options to the child class to provide a certain amount of behaviour itself.

A Child Class extending the Abstract Class:

public class Child extends Parent {
public String getSon() {
return “Sons Name”;
}

public String getDaughter(){
return “Daughters Name”;
}
...
... //Code specific to the Child class
}

Declaring Interfaces:

When you create an interface, you’re defining a contract for what a class can do, without saying anything about how the class will do it. Interfaces can be implemented by any class, from any inheritance tree. This lets you take radically different classes and give them a common characteristic.

Ex: You can create an interface Drivable which in effect means that it has the feature of being driven. Any class that implements this Drivable interface must provide an implementation of the drive() method can be driven. But how it will be driven is up to the classes to provide the implementation. Both a car and a bus can be driven but the how part is different. So the classes Car and Bus will implement this interface and provide their specific behavior about being driven.

Tip: An Interface is an 100% Abstract class

Comparison between an Abstract Class and an Interface:

While an abstract class can define both abstract and non-abstract methods, an interface can have only abstract methods. Another way interfaces differ from abstract classes is that interfaces have very little flexibility in how the methods and variables defined in the interface are declared. These rules are strict:

• All interface methods are implicitly public and abstract. In other words, you do not need to actually type the public or abstract modifiers in the method declaration, but the method is still always public and abstract. (You can use any kind of modifiers in the Abstract class)
• All variables defined in an interface must be public, static, and final—in other words, interfaces can declare only constants, not instance variables.
• Interface methods must not be static.
• Because interface methods are abstract, they cannot be marked final, strictfp, or native. (More on these modifiers later.)
• An interface can extend one or more other interfaces.
• An interface cannot extend anything but another interface.
• An interface cannot implement another interface or class.
• An interface must be declared with the keyword interface.

You must remember that all interface methods are public and abstract regardless of what you see in the interface definition.

Look out for questions where interface methods are declared with any combination of public, abstract, or no modifiers. For example, the following five method declarations, if declared within their own interfaces, are legal and identical!

void bbb();
public void bbb();
abstract void bbb();
public abstract void bbb();
abstract public void bbb();

whereas the below declarations wont compile:

The following interface method declarations won’t compile:
final void bbb(); // final and abstract can never be used
// together, and abstract is implied
static void bbb(); // interfaces define instance methods
private void bbb(); // interface methods are always public
protected void bbb(); // (same as above)

Declaring Variables in an Interface

We are allowed to declare variables in an interface. By default these variables would be constants because they would static and final. By placing the constants right in the interface, any class that implements the interface has direct access to the constants, just as if the class had inherited them.

You need to remember one key rule for interface constants. They must always be
public static final

Since the variables declared in an interface are by default public static and final, we need not mention them explicitly. But it is a good practice to do so to ensure that even novice programmers can understand the code you write.

Constructor Declarations:

In Java, objects are constructed. Every time you make a new object, at least one constructor is invoked. Every class has a constructor, although if you don’t create one explicitly, the compiler will build one for you.

Ex:
class Test {
public Test() { } // this is Test’s constructor

public void Test() { } // this is a badly named,
// but legal, method
}

If you see the example above, you would have realized that the constructor looks a lot like methods. Below are the main distinguishing factors between the constructor and normal methods:
1. The Constructor’s name is exactly the same as the name of the class
2. They do not have a return type (Please remember this. A Constructor cannot have a return type as part of the code)
3. Constructors cannot be static, abstract or final

Declaring Variables:

There are two types of variables in Java:
• Primitives - A primitive variable can be one of eight types: char, boolean, byte, short, int, long, double, or float. Once a primitive has been declared, its primitive type can never change, although in most cases its value can change.
• Reference variables - A reference variable is used to refer to (or access) an object. A reference variable is declared to be of a specific type and that type can never be changed.

We should remember that each of the primitive datatype has a particular range and by assigning values that are bigger than the size it can take would result in errors or loss of value and precision. Below are the data ranges of the primitive datatypes:

Primitive Data Type Ranges in Java
Data Type	Bits Used	Minimum Value	Maximum Value
byte	8	-27	27 - 1
short	16	-215	215 -1
int	32	-231	231 -1
long	64	-263	263 -1
float	32	n/a	n/a
double	64	n/a	n/a

The range for these floating point numbers is difficult to determine and it is not required from the exam perspective as well. Booleans and char type variables do not have a range. Booleans can be either true or false and chars can be only one character in size Ex: “A” or “B” etc

Declaring Reference Variables:

Reference variables can be declared as static variables, instance variables, method parameters, or local variables. You can declare one or more reference variables, of the same type, in a single line

Variables can be declared in multiple places inside a class which determines what type of variable gets created. They are:

Instance Variables

Instance variables are defined inside the class, but outside of any method, and are only initialized when the class is instantiated. Instance variables are the fields that belong to each unique object.

Ex:
public class Test {
private String name = “Anand”;
private String country = “India”;
}

Here name and country are two instance variables where they would be a part of an object of the class Test. Since each variable is part of the class’s instance (object), they are called instance variables.
For the exam, you need to know that instance variables
• Can use any of the four access levels (which means they can be marked with any of the three access modifiers)
• Can be final
• Can be transient
• Cannot be abstract
• Cannot be synchronized
• Cannot be strictfp
• Cannot be native
• Cannot be static, because then they’d become class variables.

Static Variables or Class Variables:

The static modifier is used to create variables and methods that will exist independently of any instances created for the class. All static members exist before you ever make a new instance of a class, and there will be only one copy of a static member regardless of the number of instances of that class.

Things you can mark as static:
• Methods
• Variables
• A class nested within another class, but not within a method (more on this in Chapter 8).
• Initialization blocks

Things you can’t mark as static:
• Constructors (makes no sense; a constructor is used only to create instances)
• Classes (unless they are nested)
• Interfaces
• Method local inner classes
• Inner class methods and instance variables
• Local variables

Method Parameters:

These are variables that are declared as part of a methods declaration. These are arguments that will be used as part of the method.

Ex: public int add(int a, int b) {
return a + b;
}

Here a and be are the method parameters.

Local Variables:

These are variables that are declared inside a method and are used for processing inside the method.

Ex: public int add(int a, int b) {
private int c = 10;
return a + b + c;
}

Here c is the local variable.

Declaring Arrays:

In Java, arrays are objects that store multiple variables of the same type, or variables that are all subclasses of the same type. Arrays can hold either primitives or object references, but the array itself will always be an object on the heap, even if the array is declared to hold primitive elements. In other words, there is no such thing as a primitive array, but you can make an array of primitives.

The main thing you need to know about arrays in the exam perspective is how to create an array and how to assign values to the array elements.

Tip: Arrays are very useful and efficient but java has other utility classes like ArrayList or Vector that might be much better in performance than arrays. These collections give us easier access to its objects and also provide utility methods that might help us process these objects

Declaring an Array of Primitives

int[] keys; // Square brackets before name (recommended)
int keys []; // Square brackets after name (legal but less
// readable)

Declaring an Array of Object References

Thread[] processes; // Recommended
Thread processes []; // Legal but less readable

We can also declare multidimensional arrays, which are in fact arrays of arrays. This can be done in the following manner:

String[][] employeeNames;
String[] employeeNames[];

Above we have a 2 dimensional array which can be thought of as an array of arrays. Notice in the second example we have one square bracket before the variable name and one after. This is perfectly legal to the compiler, proving once again that just because it’s legal doesn’t mean it’s right.

Note: We will deal with assigning values to the array in a separate chapter.


Hope this chapter on Declarations was useful. I have intentionally left of declaration of Enumerations as part of this chapter because enums need to be taken up as a separate chapter because of the amount of details involved in enumerations.

Previous Chapter: Chapter 1 - Refreshing Java

Next Chapter: Chapter 3 - Declaring Enumerations (Enums)