Comparison Between Interface and Abstract Classes

Feature	Interface	Abstract class
Multiple inheritance	A class may implement several interfaces.	A class may extend only one abstract class.
Default implementation	An interface cannot provide any code at all, much less default code.	An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.
Constants	Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional.	Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants.
Third party convenience	An interface implementation may be added to any existing third party class.	A third party class must be rewritten to extend only from the abstract class.
is-a vs -able or can-do	Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.	An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.
Plug-in	You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.	You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad. Another issue that's important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homogeneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface.
Homogeneity	If all the various implementations share is the method signatures, then an interface works best.	If the various implementations are all of a kind and share a common status and behavior, usually an abstract class works best.
Maintenance	If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.	Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.
Speed	Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty.	Fast
Terseness	The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can't call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so.	You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract.
Adding functionality	If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.	If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change

Favor object Composition over Class Inheritance

Happy New Year, a warm welcome in 2011.

Today we will see Composition vs Inheritance.

Object composition and inheritance are two techniques for reusing functionality in object-oriented systems. Inheritance is often called white-box reuse.

Object composition is a different method of reusing functionality. Objects are composed to achieve more complex functionality. This approach requires that the objects have well-defined interfaces since the internals of the objects are unknown. Because objects are treated only as "black boxes," this type of reuse is often called black-box reuse.

The advantage of class inheritance is that it is done statically at compile-time and is easy to use and disadvantages are that derived class becomes dependent on parent implementation and inheritance breaks encapsulation. Also, implementation/functionality inherited from parent class cannot be changed at runtime.

In object composition, functionality is acquired dynamically at run-time by object reference to other objects. The advantage of composition is that implementation can be replaced at run-time. It is providing encapsulation. It is independent and loosely coupled with child classes.

The disadvantage of composition is that the behavior of the system may be harder to understand just by looking at the source code. A system using object composition may be very dynamic in nature so it may require running the system to get a deeper understanding of how the different objects cooperate.

                           Inheritance                                        Composition

class Engine { }                                               class Engine { }

class Car : Engine                                          class Car : Engine

{                                                                     {

    //Do code                                                           Engine carEngine;   

}                                                                     }

How ever it is not necessary that you always use composition. There are scenarios where we have to use inheritance to create related objects; especially when we want to restrict object creation of Master Class. We can create Abstract Base class to achieve this.

Evolution of OOPs

Evolution of OOPs
Programming is the craft of transferring requirements into a process that Computers can execute. It is form of some set of information that computer can understand and work accordingly. It is like set command that you have to pass to a machine to perform some activity. Programming is same as like ordering a Pizza to a chef who can execute your order and deliver you a Pizza. It is not as simple as it looks and it is not as hard as we can imagine.

Till 1980s computers are mainly used in Government, University and Research Centers and they were mainly using Collaborative applications. But after 1980s personal computers become common and hence rise of consumption of software. High demand and enterprise applications lead to think for Object Oriented Programming languages, and Smalltalk, a first OO Programming language introduced to Computer World.

Programmers and Programming
Programmers implementing the requirements by braking down in small steps, they are writing these steps using a programming language that computer can understand. We can say programmers creates a recipe that computer can understand.

Early Programming
When computers were not much popular and mainly used in limited numbers programmers were happy doing a Sequential Programming, where there are less chances of updating the code. There were only two actors, 1) Programmer and 2) Computers (Users).

Now Days
As time passes, computer become more popular and affordable, known as Personal Computer (Desk Computer), that lead to rise in personal software/application and Enterprise Applications. A Traditional Sequential Programming has proven history but was not sufficient to frequently changing Enterprise Applications and Desktop Applications. Application becomes so complex that it is hard to maintain and code Blocks becomes so big that it is complicated to implement further changes.


More Coming Soon....