Question about Interfaces
Moderator: General Moderators
Question about Interfaces
I have an ambiguity about interfaces in programming languages I've worked with(PHP and Java).
Everywhere I've heard that an interface is just a way for enforcing subclasses to include all the functions declared in the interface. This seems completely clear but the ambiguity begins when it seems that sometimes interfaces do certain actions(Especially or maybe always in internal interfaces). For example I’ve seen a simple class does iteration by just implementing an interface and by removing the implemented interface the class iteration does not work!
I’ve also seen that in Java when you implement an interface the “Event Handling” does work and without implementing its interfaces it doesn’t!
I really appreciate if someone make it clear for me to some extent.
Everywhere I've heard that an interface is just a way for enforcing subclasses to include all the functions declared in the interface. This seems completely clear but the ambiguity begins when it seems that sometimes interfaces do certain actions(Especially or maybe always in internal interfaces). For example I’ve seen a simple class does iteration by just implementing an interface and by removing the implemented interface the class iteration does not work!
I’ve also seen that in Java when you implement an interface the “Event Handling” does work and without implementing its interfaces it doesn’t!
I really appreciate if someone make it clear for me to some extent.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Question about Interfaces
An interface is just a contract, nothing more. When you implement an interface it forces you to implement certain public methods, which is handy when you follow inversion of control/dependency injection principle.
I'm not sure exactly what your question is or if I have answered it, but interfaces are really simple, it just enforces a best practice of making sure you provide all required methods expected by a system.
I'm not sure exactly what your question is or if I have answered it, but interfaces are really simple, it just enforces a best practice of making sure you provide all required methods expected by a system.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Question about Interfaces
Much more than just practice. Good compilers are strict, and strict compilers require type matching. Interfacing allows type matching to be recognized amongst different class types.PCSpectra wrote:it just enforces a best practice of making sure you provide all required methods expected by a system.
A good example is a "Runnable" interface that implies that a run() method MUST exist in Runnable classes. So, regardless of what run() does in any given class that implements Runnable, your program knows that any Runnable object will have the run() method (which takes the same parameter types and returns the same type).
So, if you have the classes "Program," "Treadmill," and "Arena," if they all implement Runnable, even though they are not clearly related, the program knows that they all have the run() method. So, you can have an array of Runnable objects with objects of each of these three classes and call the run() method on all of them in a loop. Without an interface to tie them together, they would need to share a common parent class, which would likely make no sense.
In terms of your Java example, Java can only use objects that it knows implements the event handling interface for event handling. Even if the class has the necessary methods, Java needs that explicit definition in order to know the purpose of those methods.
This is why interfaces exist. Class types don't need to be related. Think of it as it is: an interface. A user interface may have all kinds of buttons, and all of these objects would include a run() button. The Runnable interface just informs the compiler that this run() button exists.
PHP has no compiler, but the interpreter looks at these rules, too.
Re: Question about Interfaces
Please check the following code and then run it without implementing ArrayAccess interface. You will see that it won't work.PCSpectra wrote:An interface is just a contract, nothing more. When you implement an interface it forces you to implement certain public methods, which is handy when you follow inversion of control/dependency injection principle.
I'm not sure exactly what your question is or if I have answered it, but interfaces are really simple, it just enforces a best practice of making sure you provide all required methods expected by a system.
Code: Select all
<?
//reflectionClass::export(ArrayAccess);
class users implements ArrayAccess
{
private $users;
public function __construct()
{
$this->users = array();
}
public function offsetExists($key)
{
return isset($this->users[$key]);
}
public function offsetGet($key)
{
return $this->users[$key];
}
public function offsetSet($key, $value)
{
$this->users[$key] = $value;
}
public function offsetUnset($key)
{
unset($this->users[$key]);
}
}
$users = new users();
$users['jack']="jack@some.net";
echo $users['jack']
?>- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Question about Interfaces
PHP is programmed in C. It is possible that ArrayAccess overloads the subscript operator.
Re: Question about Interfaces
Marking class as implementing ArrayAccess is your way to tell the engine 'I want those "offset..." methods called when you see subscript expression'.Appolo wrote:Please check the following code and then run it without implementing ArrayAccess interface. You will see that it won't work.
PHP does not get translated into C, so it's irrelevant. And even if it was relevant, C does not have operator overloading (it's C++ feature).superdezign wrote: PHP is programmed in C. It is possible that ArrayAccess overloads the subscript operator.
Re: Question about Interfaces
So an interface is much more than a practice, they also have their special meanings for the compiler or interpreter.superdezign wrote:Much more than just practice. Good compilers are strict, and strict compilers require type matching. Interfacing allows type matching to be recognized amongst different class types.PCSpectra wrote:it just enforces a best practice of making sure you provide all required methods expected by a system.
I think although PHP language syntax doesn't have explicit object type matching, but it handle them implicitly.superdezign wrote: A good example is a "Runnable" interface that implies that a run() method MUST exist in Runnable classes. So, regardless of what run() does in any given class that implements Runnable, your program knows that any Runnable object will have the run() method (which takes the same parameter types and returns the same type).
So, if you have the classes "Program," "Treadmill," and "Arena," if they all implement Runnable, even though they are not clearly related, the program knows that they all have the run() method. So, you can have an array of Runnable objects with objects of each of these three classes and call the run() method on all of them in a loop. Without an interface to tie them together, they would need to share a common parent class, which would likely make no sense.
Thanks, this is what I couldn't find out after reading half of a huge Java book! and instead I was mixed up because books always emphasize that interfaces are just contracts.superdezign wrote: In terms of your Java example, Java can only use objects that it knows implements the event handling interface for event handling. Even if the class has the necessary methods, Java needs that explicit definition in order to know the purpose of those methods.
Thanks, now I have a much better understanding of interfaces.superdezign wrote: This is why interfaces exist. Class types don't need to be related. Think of it as it is: an interface. A user interface may have all kinds of buttons, and all of these objects would include a run() button. The Runnable interface just informs the compiler that this run() button exists.
PHP has no compiler, but the interpreter looks at these rules, too.
Re: Question about Interfaces
Could you explain a bit more about this?Weirdan wrote:Marking class as implementing ArrayAccess is your way to tell the engine 'I want those "offset..." methods called when you see subscript expression'.
I've also saw more examples of this kind that does not work without implementing an internal PHP interface, but I cannot remember/find them at the moment.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Question about Interfaces
I think that is pretty much what I said, just not in so many words.Much more than just practice. Good compilers are strict, and strict compilers require type matching. Interfacing allows type matching to be recognized amongst different class types.
A good example is a "Runnable" interface that implies that a run() method MUST exist in Runnable classes. So, regardless of what run() does in any given class that implements Runnable, your program knows that any Runnable object will have the run() method (which takes the same parameter types and returns the same type).
So, if you have the classes "Program," "Treadmill," and "Arena," if they all implement Runnable, even though they are not clearly related, the program knows that they all have the run() method. So, you can have an array of Runnable objects with objects of each of these three classes and call the run() method on all of them in a loop. Without an interface to tie them together, they would need to share a common parent class, which would likely make no sense.
In terms of your Java example, Java can only use objects that it knows implements the event handling interface for event handling. Even if the class has the necessary methods, Java needs that explicit definition in order to know the purpose of those methods.
An interface is quite a simple concept, it's similar in nature to a abstract class with abstract methods, but unlike an ABC there are no implementations, it forces you to implement all required methods. Therefore I consider it a best practice to use interfaces when implementations can vary, such as a database provider for MySQL, MSSQL, etc.
Interfaces can also be used "technically" inside the adapters to verify the implementation actually implements all methods required, triggering and error or exception if not.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Question about Interfaces
Well, what I was trying to say in regards to this is that I don't believe that you can program this in PHP, as PHP does not have operator overloading. In order to implement something like this, it would have to be done at a lower level that has access to the semantics analyzer. As such, it is built into the language. In order for PHP to know that this is a traversable object, it needs to implement the interface. It makes me assume that the array created with the "array()" directive implements this interface as well (though I'm not sure). This is a special case that is done inside of the interpreter.Appolo wrote:Could you explain a bit more about this?Weirdan wrote:Marking class as implementing ArrayAccess is your way to tell the engine 'I want those "offset..." methods called when you see subscript expression'.
Basically, this isn't a very good example when trying to understand interfaces.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Question about Interfaces
Eh... I re-read your post a few times before actually responding. The OP was having difficulty understanding, and your explanation was vague. Also, you were missing the reasons that interfaces are actually necessary parts of OOP, not just "proper."PCSpectra wrote:I think that is pretty much what I said, just not in so many words.
- PHPHorizons
- Forum Contributor
- Posts: 175
- Joined: Mon Sep 14, 2009 11:38 pm
Re: Question about Interfaces
Hello Appolo,Appolo wrote:[SNIPPED]I’ve seen a simple class does iteration by just implementing an interface and by removing the implemented interface the class iteration does not work!
It seems that built in interfaces normally have some "magic" functionality added to them; because, in normal circumstances, implementing an interface which is totally custom built does not give any extra functionality. It is, as has been said, a guarantee of certain functionality being implemented in the object which implements an interface.
So for the built in interfaces, the extra added magic functionality should be viewed apart from the "Interface" and seen as what it really is, simply "magic". It's kind of like __get(), __set(), __construct(), etcetera.
Hope that helps.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Question about Interfaces
It is interesting that PHP allows multiple inheritance of built-in classes using implements but does not allow you to include code when you create an interface in PHP. Obviously interfaces allow multiple inheritance, unlike classes or abstracts, so it makes some kind of sense that these magic built-in use implements. It does technically imply that PHP could support multiple inheritance in the future by allowing code into interfaces. Perhaps there could be some limitations on what could be in an interface and run-time checking to deal with the diamond problem ... perhaps by not allowing overlapping method names. Probably the built-in classes are designed to avoid name collisions.
(#10850)
- PHPHorizons
- Forum Contributor
- Posts: 175
- Joined: Mon Sep 14, 2009 11:38 pm
Re: Question about Interfaces
Suppose IFoo has a blah() method and IBar also has a blah() method. Which one's "code" would be used in a class that implements both interfaces?arborint wrote:[SNIPPED] [Perhaps] PHP could support multiple inheritance in the future by allowing code into interfaces.
It is precisely the fact that interfaces don't have code that makes it possible for objects to inherit from multiple interfaces. So if one were to change php to allow code to go into interfaces (for multiple inheritance), it would make more sense to just allow classes to allow multiple inheritance. In either case, the problem of which blah() method takes precedence, or how one overrides that precedence would have to be solved.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: Question about Interfaces
C++ does it. I think that's what ~arborint was getting at. Multiple inheritance isn't at all necessary, but it can help developers save code.
For example: you make a function that is semi-specific. Specific enough that it only has a use for one particular task, but broad enough that many classes will need it. Like, creating a URL-friendly title for using in clean URLs. Useful for content URLs, user profile URLs, etc. However, you don't want it to be a global function. In order to include it in only a few classes, you would need an external "formatting" dummy class, or to re-implement the method in all of the classes that need it. That, or make it into a global function. Multiple inheritance lets you write the code once and give it to any class that needs it.
Not that it's necessary. A global function is acceptable, and a dummy formatting class can be useful for encapsulating all format related functions. These are just not the most "proper" ways of doing it.
For example: you make a function that is semi-specific. Specific enough that it only has a use for one particular task, but broad enough that many classes will need it. Like, creating a URL-friendly title for using in clean URLs. Useful for content URLs, user profile URLs, etc. However, you don't want it to be a global function. In order to include it in only a few classes, you would need an external "formatting" dummy class, or to re-implement the method in all of the classes that need it. That, or make it into a global function. Multiple inheritance lets you write the code once and give it to any class that needs it.
Not that it's necessary. A global function is acceptable, and a dummy formatting class can be useful for encapsulating all format related functions. These are just not the most "proper" ways of doing it.