In OOP why would you even want to use an interface?

Because you can then indicate things like this method takes an argument, which can be of any class that implements this interface. It’s not for the benefit of the classes that implement it, but the code that uses those classes.

For instance, one way to build an object-relational mapper in PHP might be to create an interface that all storable objects had to implement. You could then build your class hierarchy ignoring the fact that they’re all storable in your database, and put all the code relating to database access in the methods declared by the interface. This way, if there is some object that shouldn’t be stored in the database, or that requires special handling before going into the database, the code will still conform to the interface even if it doesn’t have the same implementation.

You can see this pattern in Apple’s Cocoa framework: there’s an interface called NSCoding that declares the methods necessary to serialize an object. User-created objects that conform to the NSCoding interface and implement the necessary methods can be saved to and loaded from files without any extra work on the part of the programmer.

The other principal way to do this is multiple inheritance, which causes a lot of problems.

And the reason this is a good thing is because having isolated bits of code that communicate with each other through well-defined interfaces (in the generic sense) leads to more maintainable code. Instead of knowing how the other chunk of code actually works, you just know that if you call this function with these arguments, this other thing will happen. Interfaces (in this specific sense) are a way of formalizing the contract between the caller and the called code.

@cwilbur nailed it. Great answer :)

@cwilbur has it to a tee. I think the simplest way to put it is that interfaces can help you bolster consistency. ORM is a great example; no matter what SQL code you use to pull a record from a database, the interface should be the same. If you want to abstract different kinds of databases, it shouldn’t really matter whether your SQL is optimized for PostgreSQL, MSSQL, or MySQL, the interface should be the same for all three classes.

Imagine working on a large project with a team that is faithful in using interfaces. You don’t have to look through the class to figure out what the name of getter, setter, or any other methods are, if they’re consistent it should come intuitively.

Another reason for using interfaces is to simplify unit testing. If you pass in the interface objects that the class uses, it is easy to send in stubs so that you can isolate what you want to test.

In general, using interfaces provides more flexibility than inheritance. With intefaces you are not tied to a particular parent object. I am not against inheritance but it has to be used judiciously. I would definitely use interfaces over multiple inheritance.

Sigh I fear that I don’t know enough about OOP to fully understand it yet.

I’m using classes in my current projects but I don’t think I’ve been using them correctly..

Does anyone have any good articles, or books based around OOP that I could read?

I’ve read a lot of articles that explain what OOP is but nothing that really explains proper design principles and proper implementation etc.

Someone once told me that when using objects it’ll just click on what they’re for and how to use them properly.. Unfortunately that hasn’t happened for me yet :(

One big problem is that “object orientation” is a big umbrella. Take a look at http://www.paulgraham.com/reesoo.html, for instance—nine concepts that are associated with object orientation, but not all OO languages use all nine concepts.

And another big problem is that there are a lot of books and web tutorials that explain the basic principles of object orientation, and a lot of books that deal with the advanced ramifications of object orientation, but very few resources of any sort that deal with the middle range.

And the proper design principles will vary depending on the language and (to some extent) on your philosophy. For instance, Apple’s Cocoa framework avoids subclassing for a lot of common cases by encouraging delegation instead—so instead of making a view class that inherits from NSTableView, for instance, you set the model class as the delegate of the NSTableView. And Java avoids multiple inheritance because of the problems it causes, and so to get some of the same benefit, you use interfaces—but if your language supports multiple inheritance, you don’t need interfaces at all.

@frankielaguna I’ve definitely noticed the lack of informative material that studies class design in itself that helps someone step from early beginnings to practical OOP. That’s probably the reason OOP has to “click”, if it doesn’t come to you in a dream, there’s no other way to tell you exactly what it’s all about!

What I can say is that there are two extremes: beginners who basically write their entire script as one class, and the “OOP happy”, so to speak, who make a class for every. little. thing. In my experience, successful and readable OOP code is somewhere in the middle.

While the examples you’ll find, like the iconic “Person” class, or “Car” class, seem a little far from reality and not like something you’ll approach in the wild, they are actually usable examples if you take them literally. OOP is a different way of organizing your program, not just a fancy struct. Consider those parts of your program that are objects in and of themselves. I’ve been halfway through writing classes only to realize that a big chunk of that class should have its own class, uniquely identified on its own. This largely stems from a lack of planning.

Classes are not just a collection of data, but a way of conceptualizing that data. I don’t meant to patronize you if you already know all of this, but I know getting over that speedbump was a big step when I first learned OOP.

@noyesa That made more sense than 90% of the articles I’ve read. I used to be the one who wrote everything in 1 class, then slowly moved to the person who would try and make everything into it’s own class but currently I’m the person who for each module of the site (users (user registration, login, and managment), base (handles basic things), etc) writes a class.

Thank you all so much for your input. My head hurts now :)

@frankielaguna – I completely recognize what you’re going through here, I had exactly the same when I started OOP. Nobody really explained in a good way why and especially how (that has improved a little bit), and my code used classes but was terrible and not OOP at all. The way I finally learned was by using a framework. I assume from the topics that you’re using PHP, so be sure to check out one of the many (MVC) frameworks for PHP – I quite like the Zend Framework. They often rely heavily on classes and use them the Good Way (ZF for example tries very hard to promote best practices) and in the process provide very good examples on how to use OOP, upon which the benefits will also become immediately apparent.