0

I have a confusion in why we use abstract classes or interfaces to implement or extend. interfaces doesn't contain any code so does the abstract methods. then why we use them. why don't we directly create methods and define them in our class rather we use interfaces or abstract classes. they don't contain any sort of code, we need to define them after extending them in our class. why we don't define these methods in our own class rather extend interfaces and then define them. I found such type of question asked several times in stackoverflow but couldn't understand the answer. can anyone please explain it in some simple way

ScoRpion
  • 11,364
  • 24
  • 66
  • 89
  • This is a quite simple explanation, I guess: http://stackoverflow.com/a/1221524/690897 - I know, it's tagged with java, but a concept is not bound to any specific language. This seems also very useful: http://stackoverflow.com/questions/479142/when-to-use-an-interface-instead-of-an-abstract-class-and-vice-versa – Quasdunk Jan 11 '12 at 12:54
  • Well I read that but i couldn't understand why i need it, why dont we declare these methods in our own class rather implement an interface then declare. can i do it in both ways. – ScoRpion Jan 11 '12 at 12:57
  • http://geekswithblogs.net/mahesh/archive/2006/07/05/84120.aspx – Ayush Pateria Jan 11 '12 at 12:59
  • can i have a simple real world example – ScoRpion Jan 11 '12 at 13:00
  • In the end, it's all a matter of taste, I guess :) Try to see interfaces as tools to keep your architecture clean and your implementation abstract. An interface is like a contract and sort of implements the OOP concept of polymorphism. – Quasdunk Jan 11 '12 at 13:01

7 Answers7

3

The power of abstraction and interfaces comes from the fact that you can separate responsibilities and write modular code: One part of your (or someone else's) code may only care that you have an Animal and provide facilities to deal with Animals, without needing to know how they move or feed. A different part of your code may only care about defining lots of concrete animals, like Dogs, Birds, etc., with all the details of how they actually implement all their features.

By making the concrete classes (Dog, Bird, ...) extend a common, abstract interface (Animal), you can use a any now and future concrete class in a library written for the abstract interface -- you don't need to ask the library author to change the library to accommodate new Animals, and the library author doesn't need to know how features are concretely implemented.

For example, if you had two single algorithm, FeedBreakfast and FeedDinner, that would require a member function Animal::gobble(), then without inheritance you would need to implement each algorithm for each animal - i.e. you'd end up with M * N amount of code! By using a common, abstract interface you reduce this to M + N -- M algorithms and N concrete classes, and neither side needs to know of the other -- they just both need to know the interface.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • Can i conclude we make interfaces as a part to remember the functionality of a class that is going to implement it – ScoRpion Jan 11 '12 at 13:04
  • @Showket: It's more than just remembering it for yourself. It's about providing a contract to *other* users (including yourself) and hiding the implementation details, so that you only need to expose *relevant* information. This in turn means that users of the abstract interface cannot possibly know of your implementation and start depending on it, so if you like to refactor your concrete class later, you don't have to worry about breaking existing code. Keep the public interface as small as possible, and you will only need to guarantee *the interface* in the future. – Kerrek SB Jan 11 '12 at 13:08
  • Thanks a lot for so nice answer. Can u please explain me how interfaces reduce amount by (M+N - M ) – ScoRpion Jan 11 '12 at 13:11
  • 1
    @Showket: You write `M` algorithms for `Animal`s and `N` concrete animals. Without the interface, you'd need `FeedBreakfastToDog`, `FeedDinnerToDog`, `FeedBreakfastToBird`, etc., i.e. `M * N` implementations. – Kerrek SB Jan 11 '12 at 13:14
1

The idea behind an abstract class is that you can define some common functionality of a set of similar classes, but leave other details up to the implementing (extending) classes. In a way they are similar to interfaces, except that you can actually implement some of the functions in the abstract class.

But what's the point, I hear you ask? Well, you only have to write the common code once, although you can do this in a concrete (non-abstract) base class too. But also you may not want other programmers to instantiate the base class, so this is where the real power of abstract classes come in.

Let me show an example to help illustrate my point. Imagine you are writing a program to classify all of the animals in a zoo. Animals can be classified into certain types, bird, reptile, mammal, insect, arachnid, fish, etc, and then down to their species such as dog, cat, parrot or kangaroo. The base class, Animal, can provide some of the common functionality to all of these. It might have a function called eat() which all animals do in a similar way and so the function is written out to describe the process of an animal eating. It might contain another function, walk(), but this one is abstract, since different animals will implement this in a different way. All subclasses of the Animal class will need to implement this method.

The major bonus of this is that somewhere in your code you can call a function that takes an Animal as a parameter. You know that you can call the eat() and walk() functions on this parameter because all Animals can eat and walk. This is called polymorphism and is an important trait of Object Oriented Programming.

I hope this has helped you. Please feel free to discuss or ask further questions if you still can't see the value of abstract classes.

vivek s vamja
  • 1,001
  • 10
  • 11
1

Statically typed languages need to use this method to enable polymorphism. That is, you can write your code in terms of your abstract base class. Then you can "plug" in any subclass as an extension. This is called Liskov Substitution principle, or Open/Closed principle. Technically, this is called dynamic binding. That is, the method to call is selected during runtime depending on the subclass.

With dynamically typed languages the situation is completely different. I don't know if PHP is dynamically typed (I suspect it is), but in Ruby or Javascript, for example, you can program in terms of any object that conforms to a specific interface. That is, if your code expects an object that has a method called Print you can substitute with any other object that also has a Print method, without deriving from a common base class. The method will be looked up during runtime, that is why these languages are called "dynamic".

Hope this helps!

Daniel Lidström
  • 9,930
  • 1
  • 27
  • 35
  • Javascript is a different animal, because its object model is prototype-based and not class-based. For class-based OO languages like (for better or worse) PHP, interfaces are a matter of design moreso than of implementation, so the dynamic typing doesn't really make for a strong argument, in my opinion. – Kerrek SB Jan 11 '12 at 13:42
1

You use abstract classes or interfaces when you want to establish a protocol.

It sounds simple, but it's a very powerful concept. If you are forced to adhere to rules, then you cannot break them. If you cannot break the rules, you adhere to the protocol. Therefore, all the classes that implement your interface should inherently be compatible with each other. Naturally, there are exceptions among human kind who are able to break these rules by creating code that even interpreters cry when they have to parse it but that's a bit of an offtopic :)

N.B.
  • 13,688
  • 3
  • 45
  • 55
1

For an interface, imagine you have a Class called "Message". This implements the Interface called SendMessage, which has a method definition of Send.

If you then create two subclasses of "Message". One could be "Email" and one could be "InstantMessage".

Now these both have the method Send(), which is defined in the SendMessage interface, and are blank. This now allows you to define differently what the Send() method does. However, because we know the classes Email, and InstantMessage use the interface SendMessage, we know that they both have the method Send();

So you could call Email.Send(), and InstantMessage.Send(), but do two different things. An interface defines methods available to several objects, but with the same method name.

Davos555
  • 1,974
  • 15
  • 23
  • so why dont i create a method send inside my Message class directly or in its subclases rather i implement an interface and then define the same function with same code i would have used in my own method? – ScoRpion Jan 11 '12 at 13:15
  • It defines a kind of framework - you could be writing one bit of code (the Email class) and someone else could be writing the InstantMessage class. But they'd both share the .Send() method identifier, but most likely the Send method would have different internal structure, as they do two different things. If you wanted the Send() method to do exactly the same thing across both classes, that's when you would use inheritance. Yes you could write your own non interface methods within these classes, but the interface allows a strict definition of what method names should be. – Davos555 Jan 11 '12 at 14:15
  • What parameters they take and what they return. Other programmers can also view the interface definition and know that any class that implements this interface has these methods. – Davos555 Jan 11 '12 at 14:17
1

Abstract classes/interfaces are mostly design time considerations. By defining methods as abstract and therefore the classes as abstract too.. we are ensuring that these methods will definitely be implemented by deriving classes. If they do not implement them they also become abstract.

Interfaces provides the luxury of distributing the must implement methods into different categories, so the required number of interfaces can be implemented.

Sasidhar R Kondapalli
  • 21
  • 1
1

the abstract classes guarantee that can't be instantiate, this is because are a generalization. for example, in a game, exist a class player, but also exist classes defender and forward. the class player is the parent class of both classes. not is practice create a object player, because a team need a especific player.

The interfaces are related with polymorphism. every class, use methods according to its behavior.

i hope this help you

chenio
  • 592
  • 3
  • 11
  • 27