Some answers here are very generic stating that an interface
is a contract. It's difficult to say they are a contract when there is no scope for interfaces and classes in PHP. So it's impossible to enforce the contract. There is nothing stopping a developer from instantiating a class and ignoring the interface. So the contract description isn't that clear to developers who haven't used Java or C++ before.
So what's it all about?
Your example is not a very good one. UserInterface
to AbstractUserClass
to GenericUserClass
doesn't really show the benefits of what is going on. So let me expand on that a bit.
Why do we have interfaces, because an object can implement multiple interfaces. Think of an interface not as methods but as a defined behavior for a class. The interface is saying "I can behave like a user". It doesn't matter how the code achieves this. Just that it supports this interface.
The key to good interface design is not to create multi-purpose interfaces. Let each interface define a single behavior. This makes it much easier to create single purpose classes that work upon those kinds of objects. Instead of having one UserInterface
you might expand that to include AdminInterface
, AuthenticatedUserInterface
and UserPermissionsInterface
. So later in your code you can ask an object if it supports the AdminInterface
and if so, then that user is an administrator.
Why do we have abstract classes?
Interfaces, interfaces, everywhere interfaces... One of the drawbacks to using interfaces is that an interface implements absolutely no code. For every interface a programmer must implement at least one class. A good framework that uses interfaces will provide you with a wide range of already implemented abstract classes that give you a starting point to using those interfaces. A bad framework is one that requires many interfaces and gives you nothing to start from.
Avoid the super abstract class that implements many interfaces and provides most of the functionality for those interfaces. It's also heavily inherited by many other classes.
What you want are small abstract class that implement an interface from different perspectives. You might want to create a couple of classes that implement UserInterface
like this AbstractInvalidUser
, AbstractAnonymousUser
or AbstractAuthenticatedUser
. Later you might need to use Facebook for logging in a user. You can then create a FaceBookUser
that extends AbstractAuthenticatedUser
. It's clear now what each abstract class does but they all implement the UserInterface
.
So now the big question "Where do all the methods go?"
The key to creating maintainable source code is to always reduce dependencies down to their smallest part. That means you do not want source code using FaceBookUser
when all it's doing is displaying the current user's name. If everything in your source code is using FaceBookUser
then it's difficult to move that class to another folder or rename that class. It's easier for you to just use UserInterface
to display a user's name and now all that source code doesn't care if it's Facebook, Google+ or your own sign in. The dependency is kept small because the interface is simple and single purpose.
Because interfaces separate code from the implementation of the interface. Your other code doesn't care if the current object is a wrapper class, delegate class, super heavy class or just a simple class. As far as the code cares it's just a UserInterface
reference.
Interfaces are tools that help you create management code. Place methods in interfaces so you don't create dependencies between classes. You create break up your dependency by creating more then one interface.
That is what people mean when they call it a contract thingy.