3

So, I am starting to gasp the concept of abstract and interface in PHP.
But when is it really ever useful?

Sure I can with an interface make up the rules for my classes, so they all follow a specific pattern. But when is it really useful?

And why should I make an abstract class instead of just making a class that works by it own but is useful for other classes.
Abstract I perhaps can put my head around and see a good use, for example by making a general class. Like making a abstract Database class, then extending it onto a Mysql- and a MsAccess database class. Giving both similar functions to work with, allowing seamless experience in both cases.

But really, could anyone give me a better example of when abstract and interface are really useful?
And please note, I do know how it works, or how to write the code, just not how or when to use it.

Thanks!

lejahmie
  • 17,938
  • 16
  • 54
  • 77
  • possible duplicate of http://stackoverflow.com/search?q=abstract+vs+interface – Gordon Feb 14 '12 at 10:01
  • oh come on guys. whats the likelihood of this not being a duplicate? Why you answer it? – Gordon Feb 14 '12 at 10:04
  • 1
    possible duplicate of [Interface vs Abstract Class (general OO)](http://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo) – hakre Feb 14 '12 at 10:05
  • Thanks @hakre, and I am very sorry, I didn't find those similar questions mentioned. Perhaps because I didn't think of it as a battle between the two, a versus, but two things separate, in two different arenas. I Still do think my question is a valid question since it is set in another mindset, frame if you so want. But I do appreciate the links to the question threads for further reading. – lejahmie Feb 14 '12 at 10:17
  • @jamietelin your question is valid as such, but it has been answered before, which makes it by SO's definition, a duplicate. There is nothing particularly new here, so it should be closed. On a sidenote, you'll find further possible duplicates even when not using "vs" in the search: http://stackoverflow.com/search?q=abstract+interface – Gordon Feb 14 '12 at 10:22

4 Answers4

8

Abstract means "here is a pattern for your class, and some code that can start you off". The designer of the abstract class can mark some methods as needing to be provided by the extending class (abstract), or as final, which means the class can't override them.

Interface means "here is a pattern for your class, but you have to write all the code yourself". Any methods and properties declared in the interface must be provided by the class that implements the interface.

So essentially a rule of thumb will be:

If you have code that can or must be used by the descendant classes, you need an abstract class. If you only have method and property declarations, you can use an interface.

Don't forget, using abstract classes limits you to some extent, because a descendant class can only extend one class, whereas it can implement any number of interfaces.

lonesomeday
  • 233,373
  • 50
  • 316
  • 318
7

An interface is not a class, while an abstract class is already a class.

As every class has an interface (by definition), the interface allows you to specify an interface next to any class, be it abstract or not.

Programming against interfaces then allows you to replace one class with another one while keeping the same interface. So it makes your code less coupled. It's not programmed against concrete classes any longer but "only" against more lightweight interfaces. An interface then is useful if you don't want to program against concrete class names but against types. You can replace an object then with any other object that implements the same interface.

An abstract class on the other hand - even called abstract - is pretty concrete. However, it's not final, so it forms a pattern of a class, like a specification how a class that extends from it should be written for a certain functionality. As it's abstract, it can't come to live without extending from it. Abstract classes are used to create base classes with code that will be used more than once to reduce code duplication and not being able to instantiate directly.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • So, an interface is just a way to keep the programmer from forgetting the patterns? So to say, it's a reminder of how to code, or instructions for future coders who obviously do not share the same memory as the first coder (if we in the future does not invent a better human memory sharing, a.k.a talking, method) ^^ – lejahmie Feb 14 '12 at 10:35
  • At least you could use an interface that way :) I would not call it "forgetting" but just to have it defined, the interface is specified. Sure this is good for team-work, but also for making changes to concrete classes over time as it's not coded against a certain class but just the interface. The class can change or it can be swapped (testing, application growth). Some coders take it that far to always have an interface before coding the class, but from what I know this is sometimes superfluous because not a necessity. Just saying. – hakre Feb 14 '12 at 11:45
2

Interface is nothing but the skeleton structure of a class and it is not class. we can just implement that class and add some extra feature to make more clear. The implements keyword can be used for interface .In general way implement is used in interface to implementing the features.

abstract is a class which hides some of features and only just shows the necessary features. Extend keyword can be used for abstract class. In general ways extends can be used to extends the features of abstract class.

Sackline
  • 31
  • 4
2

An interface works like a contract. If a class implements an interface, other code that uses this class now knows it supports certain features.

The best example of an interface in PHP is the Iterator interface.

The benefit of interfaces is that classes can implement multiple. 'Extending' does not allow this. This means that a subclass can implement an interface, but it's parent doesn't have to.

Read up on design patterns. A lot of this you'll find covered, and you'll never have doubt again in which cases it makes sense. 'Head first design patterns' I thought to be a good book, very nicely written. Although they use Java in their examples, most stuff is very much applicable in PHP.

I have one more real-life scenario.

Our application always throws exceptions everywhere whenever an error occurs. Every type of exception gets its custom class. An example of this is a RecordNotFound exception.

If exceptions are not caught, there's a top-level exception block, which looks a bit like this:

try {

 // Do everything in the app!

} catch (Exception $e) {

  // draw a good error page

}

In some cases exceptions need to be mapped to certain HTTP status codes, such as 404 (not found). Therefore we have this interface:

interface HTTPException {

  function getHTTPCode();

}

any exception, no matter how deep in the inheritance tree can now implement this interface and emit a specific HTTP status code.

I even created interfaces, without any methods. I'll leave it to you to try to think of a reason why that may makes sense.

Evert
  • 93,428
  • 18
  • 118
  • 189