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: 

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 Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to