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.
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
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
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
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
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.