Abstract Vs Interfaces

abstract An formally unfinished class or method, marked with the keyword abstract. It is a way of preventing someone from instantiating a class that is supposed to be extended first. An abstract class is deliberately missing some or all of the method bodies. An abstract method is deliberately missing its method body. An abstract class is similar to an interface which is missing all the method bodies. An abstract class provides a base for someone to extend an actual class. You can't use new on abstract classes, but you can use abstract references, which always point to objects of a class that extends the abstract class. Interfaces are implicitly abstract as are all their methods. To use make practical use of an abstract class, you must define a non-abstract class that extends the abstract one. It can use any of the inherited non-abstract methods. It must implement any of the abstract ones. Sometimes a abstract class may extend another abstract class. In that case it need not implement all the non-abstract methods. Interfaces Under the hood, an interface is like a class with some restrictions. 1. All its methods must be abstract instance methods, no static methods allowed. 2. Yet, all the variables defined in an interface must be static final, i.e. constants. Happily the values need not be known at compile time. You can do some computation at class load time to compute the values. The variables need not be just simple ints and Strings. They can be any type. 3. No static initialiser blocks. You must do your initialisations in one line per variable. And, of course, no static initialiser helper methods defined in the interface. If you need them, them must be defined outside the interface. Instantiating interface methods are always instance methods. To use them, there must be some associated Object that implements the interface. You can't instantiate an interface directly, but you can instantiate a class that implements an interface. References to an Object can by via the class name, via one of its superclass names, or one of its interface names. Under what circumstances would you use abstract classes instead of interfaces? When you declare a method as abstract, can other nonabstract methods access it? In general, could you explain what abstract classes are and when you might use them? Those are all excellent questions: the kind that everyone should ask as they begin to dig deeper into the language and object-oriented programming in general Yes, other non abstract methods can access a method that you declare as abstract. But first, let's look at when to use normal class definitions and when to use interfaces. Then I'll tackle abstract classes.

Class vs. interface

Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently. For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program. With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of

course, you'll need some plumbing to properly instantiate the algorithm strategies you will need. This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity. Interface vs. abstract class Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks. Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some applicationspecific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class. Many developers forget that a class that defines an abstract method can call that method as well. Abstract classes are an excellent way to create planned inheritance hierarchies. They're also a good choice for non leaf classes in class hierarchies. ********************************************************************************** The Main Difference Between the Abstract Class And the Interface are: 1) When inheriting A Interface We have to inherit all the methods of the Interface there's no other option whereas with abstract classes we can inherit the members that we are in need of. 2) The Main difference between these is that Interface cannot have any declaration within it. Just the interface has to have body of the method and the method is to be used by the classes inheriting it. Whereas in the case of Abstract Class it can have declarations (Other than the abstract method) and it can be further extended in the classes inheriting the Abstract Class. ****************************************************** Abstract Class: A class that cannot be instantiated. An abstract class is a class that must be inherited and have the methods overridden. An abstract class is essentially a blueprint for a class without any implementation. Interface: Interfaces, like classes, define a set of properties, methods, and events. But unlike classes, interfaces do not provide implementation. They are implemented by classes, and defined as separate entities from classes ******************************************************** Abstract Class: (1) It contains both abstract methods and non abstract methods (2) object can't be created just through reference we are calling all the methods (3) it is implemented by subclass , i.e which class is extended from this,abstract class contains only non abstract, this situation also code will compile fine, but problem at runtimeabstract can't be declared with a Final, Synchronized, Native, just your

requirements you implement some methods in the abstract classthis class also contain Constructor. ======== Interface contains all abstract methods,all methods compulsory implemented by particular classinterface does not contain Constructor, Abstract Classes: Classes which cannot be instantiated. This means one cannot make a object of this class or in other way cannot create object by saying ClassAbs abs = new ClassAbs(); where ClassAbs is abstract class.Abstarct classes contains have one or more abstarct methods, ie method body only no implementation.Interfaces: These are same as abstract classes only difference is we an only define method defination and no implementation.When to use wot depends on various reasons. One being design choice.One reason for using abstarct classes is we can code common functionality and force our developer to use it. I can have a complete class but I can still mark the class as abstract.Developing by interface helps in object based communication. When to use Interface over abstract class? abstract classes are designed with implemantion gaps for sub-class to fill in. interfaces are sintacticlly similar to classes but they lack insance variables & methods. abstract classes can also have both abstract methods & non-abstract methods. where as in interface methods are abstract only, & variables are implicitly static&final. When to Use Inheritance Inheritance is a useful programming concept, but it is easy to use inappropriately. Often interfaces do the job better. This topic and When to Use Interfaces help you understand when each approach should be used. Inheritance is a good choice when: Your inheritance hierarchy represents an is-a relationship and not a has-a relationship. You can reuse code from the base classes. You need to apply the same class and methods to different data types. The class hierarchy is reasonably shallow, and other developers are not likely to add many more levels. You want to make global changes to derived classes by changing a base class. These considerations are discussed in order below. Inheritance and "Is a" Relationships Two ways to show class relationships in object-oriented programming are "is a" and "has a" relationships. In an "is a" relationship, the derived class is clearly a kind of the base class. For example, a class named PremierCustomer represents an "is a" relationship with a base class named Customer because a premier customer is a customer. However, a class named CustomerReferral represents a "has a" relationship with the Customer class because a customer referral has a customer, but a customer referral is not a kind of customer. Objects in an inheritance hierarchy should have an "is a" relationship with their base class because they inherit the fields, properties, methods, and events defined in the base class. Classes that represent a "has a" relationship with other classes are not suited to inheritance hierarchies because they may inherit inappropriate properties and methods. For example, if the CustomerReferral class were derived from the Customer class discussed previously, it might inherit properties that make no sense, such as ShippingPrefs and LastOrderPlaced. "Has a" relationships such as this should be represented using unrelated classes or interfaces. The following illustration shows examples of both "is a" and "has a" relationships.