Friday, April 12, 2013

Interfaces and Abstract Classes


Interface
In its most common form, an interface is a group of related methods with empty bodies.
A bicycle's behavior, if specified as an interface, might appear as follows:
interface Bicycle { 
    //  wheel revolutions per minute
    void changeCadence(int newValue); 
    void changeGear(int newValue); 
    void speedUp(int increment); 
    void applyBrakes(int decrement);
}

Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler. If your class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile.

class ACMEBicycle implements Bicycle { 
    // remainder of this class 
    // implemented as before
}

Interfaces are similar to abstract classes but all methods are abstract and all properties are static final. Interfaces can be inherited (ie. you can have a sub-interface). As with classes the extends keyword is used for inheritence.Java does not allow multiple inheritance for classes (ie. a subclass being the extension of more than one superclass). An interface is used to tie elements of several classes together. Interfaces are also used to separate design from coding as class method headers are specified but not their bodies. This allows compilation and parameter consistency testing prior to the coding phase. Interfaces are also used to set up unit testing frameworks.
Abstract class

An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed.
An abstract method is a method that is declared without an implementation (without braces, and followed by a semicolon), like this:
abstract void moveTo(double deltaX, double deltaY);
If a class includes abstract methods, the class itself must be declared abstract, as in:
public abstract class GraphicObject {
   // declare fields
   // declare non-abstract methods
   abstract void draw();
}
When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class. However, if it does not, the subclass must also be declared abstract.

What is the difference between an Interface and an Abstract class?


An abstract class can have instance methods that implement a default behavior. An Interface can only declare constants and instance methods, but cannot implement default behavior and all methods are implicitly abstract.
An interface has all public members and no implementation. An abstract class is a class which may have the usual flavors of class members (private, protected, etc.), but has some abstract methods.
An interface is a nonfunctional class that can contain constants and method declarations but no functional methods. It may seem, logically, if there is no functionality it might as well be a bunch of  statements. Interfaces are used when a class must behave like more than one type of object; in effect, it inherits methods and data from more than one super-class.
Interfaces are a way for the compiler to ensure that an object being used in a method has all the needed methods

When an Abstract Class Implements an Interface

In the section on Interfaces, it was noted that a class that implements an interface must implement all of the interface's methods. It is possible, however, to define a class that does not implement all of the interface methods, provided that the class is declared to be abstract. For example,
abstract class X implements Y {
  // implements all but one method of Y
}

class XX extends X {
  // implements the remaining method in Y
}
In this case, class X must be abstract because it does not fully implement Y, but class XX does, in fact, implement Y.



Java coding concepts

Coding concepts:

• Apply OO concepts like inheritance, polymorphism and encapsulation.
• Program to interfaces not to implementations.
• Use of relevant design patterns.
• Use of Java collections API and exceptions correctly.
• Stay away from hard coding values.

Saturday, August 28, 2010

What is a framework?

Last week a friend of mine who is attending a course on web application asked me what is a fremwork? Here is what I tried to explain him:

A framework is a generic architecture which build an infrastructure to develop applications in an specific technology. In simple words it is a set of basic classes and interfaces which build the infrastructure of an application.

Based on this definition it’s easy to think that using a framework is like using an API, when there is a big difference between these two. An API, e.g. Java, the classes are used by developer to do specified functionality: in this case our code call the existing code to do some function but the control of the application flow is by our code.
But using a framework means following an specific architecture; to be more precise extending the framework classes a/o implementing it’s interfaces. In this case the components of the framework have the control of the application flow.

A framework does several things:
• it makes it easier to work with complex technologies
• it ties together a bunch of discrete objects/components into something more useful
• it forces the team (or just me) to implement code in a way that promotes consistent coding, fewer bugs, and more flexible applications
• everyone can easily test and debug the code, even code that they didn't write

Maybe the best defintion is from the authors of Design Patterns:
"When you use a toolkit, you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls."
"Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent o their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you."
"If applications are hard to design, and toolkits are harder, then frameworks are hardest of all. ...Any substantive change to the framework's design would reduce its benefits considerably, since the framework's main contribution to an application is the architecture it defines. Therefore it's imperative to design the framework to be as flexible and extensible as possible."

In conclusion a framework is considered as part of an exisiting software where inserting your code; based on the rule "don't call us we call you". The framework classes will call your application code.