Interface Vs Abstact
0 likes821 views
This document discusses the differences between interfaces and abstract classes in software development. It explains that interfaces define a contract that implementing classes must follow, while abstract classes can provide default functionality for subclasses. The key differences are that interfaces cannot contain method implementations, but abstract classes can, and changing an interface can break implementing classes, while extending an abstract class allows inheriting new functionality. It provides examples of when each would be preferable, such as using interfaces for unrelated classes and abstract classes for closely related subclasses that share common behavior.
Interface Vs Abstact
- 1. INTERFACE VS ABSTARCT CLASS Ever thought of their differences in real time? This is the frequent important question asked in the interviews. Many people give a canned response like “You can define default functionality in an abstract class and you can just define functions in an interface”. The curve ball is thrown when you ask “Why would you use one over the other?” That will earn you the ‘deer in headlights’ look. Some reply “I never had to use that so I don’t know”. So what are the great differences these two entities have in Software Development? At the top level, there are a few basic differences. Abstract classes allow for default function definition. This means that whatever class extends the abstract class will have access to this. If we have a base class where all the classes will perform the same function, then we can define that in our Abstract class. An interface is a list of functions or properties that if a class implements it, it will have to have those functions defined within it. It is a situation of “Is-A” vs. “Can-Do-this”. Objects that extends an Abstract class “Is-A” base class. Objects that implement “Can-Do-This”. Now if I asked this question and got the answer, yes, that would be the correct answer. However, I want to know why one would want to use an interface over an abstract class, and vice versa. In this post I explain where exactly the interface is used and so do the abstract class. Interface and its use: • It is Purely Abstract • It’s having Fixed Functionality • If an Interface changed, all the underlined classes will change. Example: Inject Business Method to an Interface A (New Story or Feature) Where to add it? Belongs to Interface A? Not belongs to Existing Interfaces? Add to Interface A Add a new Interface B All underlying class changes May be used in new classes or some (not all) of the Underlying classes of Interface A Called Extensibility of Interface A Called Multiple Inheritance. • This scenario is not applicable when Interfaces (fixed) are sold across Business. o Example: Service Contracts
- 2. • This is used when no need of Massive hierarchical framework. Example 1: Inherits implements Interface A Class B <--------------- Class B Example 2: Let’s have an interface for a Director and another interface for an Actor. Public interface Actor { Performance say (Line l); } Public interface Director { Movie direct (boolean goodMovie); } • In reality, there are Actors who are also Directors. If we are using interfaces rather than abstract classes, we can implement both Actor and Director. • We could even define an ActorDirector interface that extends both like this: Public interface ActorDirector extends Actor, Director { ... } • We could achieve the same thing using abstract classes. • By using Abstract class would require up to 2^n (where n is the number of attributes) possible combinations in order to support all possibilities. Ex: ActorDirector, DirectorActor….. Why to prefer an Abstract Class? Abstract classes allow you to provide default functionality for the subclasses. Common knowledge at this point. Why is this extremely important though? If you plan on updating this base class throughout the life of your program, it is best to allow that base class to be an abstract class. Why? Because you can make a change to it and all of the inheriting classes will now have this new functionality. If the base class will be changing often and an interface was used instead of an abstract class, we are going to run into problems. Once an interface is changed, any class that implements that will be broken. Now if it’s just you working on the project, that’s no big deal. However, once your interface is published to the client, that interface needs to be locked down. At that point, you will be breaking the client’s code. • Its contains Default Functionality & abstract methods Concrete Methods Used in Versioning by overriding the default functionality in new version (class that extends previous abstract class)
- 3. • Abstraction used with polymorphism is called Versioning. • If we have common functionality used in a hierarchy of classes then put them in Abstract class. Whenever we need to override the existing functionality we should cut a branch of underlying classes and inherit from parent abstract class (which contains common functionality). Example: Some common functionality is used across the hierarchy B-C-D-E-F. If you want to change the functionality how the D object works then you need to cut the tree and attach E-F to A. Common Common functionalit Abstract Class functionalit y AA y A A B C A Used D Overridden With new functionality Cut Tree E E F F Frameworks are a good place to show when and where to use both an abstract class and an interface. Another general rule is if you are creating something that provides common functionality to unrelated classes, use an interface. If you are creating something for objects that are closely related in a hierarchy, use an abstract class. An example of this would be something like a business rules engine. This engine would take in multiple BusinessRules as classes perhaps? Each one of these classes will have an analyze function on it. public interface BusinessRule{ Boolean analyze(Object o); }
- 4. This can be used ANYWHERE. It can be used to verify the state of your application. Verify data is correct. Verify that the user is logged in. Each one of these classes just needs to implement the analyze function, which will be different for each rule. Where as if we were creating a generic List object, the use of abstract classes would be better. Every single List object is going to display the data in a list in some form or another. The base functionality would be to have it go through its dataprovider and build that list. If we want to change that List object, we just extend it, override our build list function, change what we want and call super.buildList(); Almost everyone knows that interfaces means you are just defining a list of functions and that abstract classes has the option of providing default functionality. The snags come when you drop the ‘why would I use one over the other?’ Abstract classes and interfaces are some of the most important fundamentals of object oriented programming. Just knowing the differences between the two is not enough. When you can look at a situation and make a strong recommendation, you will know you have a much stronger knowledge of object oriented programming. Also it helps during interviews.