On 17 May 2013, at 15:04, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> Stuart: > > You said: > >> An interface does what it says on the tin: it describes an interface that a >> class can then tell the world it implements. >> >> An abstract class provides functionality as well as an interface >> description. An abstract class cannot be instantiated, it can only be >> extended. >> >> The logging example given by someone earlier in this thread is the most >> common example given for interfaces. This is where the interface is defined >> as an API for others to implement and/or use which then enables users to >> pick and choose the combination of implementations they want to use based on >> their requirements without needing to change any of the code of either class. > > I understand the "stated" differences between abstract and interface. I can > cite what the differences are, but I don't see the practical application > differences. To me there is no difference between an abstract class (without > method declarations) and an interface. That's true, there is no difference if the abstract class has no method declarations. But by the same token, that's the difference. It's a syntactical difference rather than a conceptual difference. > However, I view an interface as a statement (a contract) where IF you want > someone to use your code you outline the methods you require them to > flesh-out in their code -- but I would like to see a simple example of that. That's not what an "interface" is for. I can see how the word is confusing as you can call the API of both an interface and a class (abstract and not) an interface, but in this context the word interface means the thing itself, not an aspect of the thing. An interface is an interface and does nothing more than define the API. An abstract class may also have methods and member variables. > I vaguely get the logging example given by Larry, but I'm not good at > abstract thinking -- I need a concrete simple example. > > I tried to create a demo where I had a Toaster Class that contained > breadNumber() and toastSetting() methods and then created an interface so my > students could use the Toaster, but it didn't really hold up as well as I > wanted. > > So, can anyone give me a simple example where an interface is used so I can > easily explain why they are important? I've knocked up a quick example of the logger use case: https://gist.github.com/3ft9/5599326 Note that if I publish that iLogger interface to others and let them provide implementations against it people can use their logging classes with my user class without any changes. Yes, this could be accomplished by using "abstract class" instead of "interface" but then it's more than just an interface that I'm publishing. If you're looking for a reason why interfaces exist when abstract classes can accomplish the same task you need to talk to someone more academically minded than me. For me, interfaces have their place because they specifically limit what you're getting from a third party to an API definition, rather than it also containing additional code that should be audited before being used in your software. Your toaster example would work, but I think you need to switch from the large object to a smaller aspect for it to make sense. Rather than being able to replace the whole toaster from their code, imagine if they wanted to replace a module within the toaster that determines the pattern to be burnt on to the bread. The Toaster class could optionally take an object that implements iToasterPattern which the students could supply to change the pattern burnt. To enable them to use that you would provide them with the API to the Toaster object so they can talk to it, and the iToasterPattern interface so they can provide their own implementation of iToasterPattern. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
