SitePoint Sponsor |
|
User Tag List
Results 1 to 16 of 16
Thread: Interface
-
Jul 27, 2007, 07:54 #1
- Join Date
- Feb 2005
- Location
- Beyond the seas there is a town
- Posts
- 711
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Interface
Hello!
http://www.artima.com/designtechniques/interfaces3.html
interface Talkative {
void talk();
}
abstract class Animal implements Talkative {
abstract public void talk();
}
class Dog extends Animal {
public void talk() {
System.out.println("Woof!");
}
}
class Cat extends Animal {
public void talk() {
System.out.println("Meow.");
}
}
class Interrogator {
static void makeItTalk(Talkative subject) {
subject.talk();
}
}
Given this set of classes and interfaces, later you can add a new class to a completely different family of classes and still pass instances of the new class to makeItTalk(). For example, imagine you add a new CuckooClock class to an already existing Clock family:
class Clock {
}
class CuckooClock implements Talkative {
public void talk() {
System.out.println("Cuckoo, cuckoo!");
}
}
Because CuckooClock implements the Talkative interface, you can pass a CuckooClock object to the makeItTalk() method:
class Example4 {
public static void main(String[] args) {
CuckooClock cc = new CuckooClock();
Interrogator.makeItTalk(cc);
}
}
As You see,He adds new different family class and uses the interface.
Is it possible to do that in PHP?I shall build a boat,I shall cast it in the water,
I shall sail away from this strange earth,
Where no one awaken the heroes in the wood of love
-
Jul 27, 2007, 08:37 #2
- Join Date
- Aug 2006
- Posts
- 41
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
yes, but you don't need to. The following code will work the same as above, but without the Interface and Abstract class.
PHP Code:class Cat {
public function talk() {
echo "Meow";
}
}
class Dog {
public function talk() {
echo "woof!";
}
}
class Interrogator {
public static function makeItTalk($subject) {
$subject->talk();
}
}
-
Jul 27, 2007, 08:40 #3
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Yuk!!
You can do the same, although remember that with an abstraction, you cannot declare in an abstract class, a method to be abstract if it's declared within an implemented interface,
PHP Code:interface QTalkative {
public function talk();
}
abstract class QAnimal implements QTalkative {}
final class QDog extends QAnimal {
public function talk() {
echo 'Woof!';
}
}
final class QCat extends QAnimal {
public function talk() {
echo 'Meow!';
}
}
final class QInterrogator {
static public function makeItTalk( QTalkative $subject ) {
$subject -> talk(); // visitor
}
}
-
Jul 27, 2007, 08:56 #4
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
PHP Code:abstract class QAnimal implements QTalkative {}
PHP Code:interface QAnimal extends QTalkative {}
Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
-
Jul 27, 2007, 10:21 #5
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You could do that I suppose, but I was just going by the example posted
However when it comes to extending on an interface I would only do so if there were commonality that could be shared, so not to introduce duplication, for example,
PHP Code:interface QAction_Handler_Interface extends QComposite_Interface {}
This way, I can still declare QAction_Handler_* as a typeof QComposite but have the ability to allow QAction_Handler_* extend if I ever have to
So you see... You have greater freedom with interfaces than you do with an abstraction but you know that already
-
Jul 28, 2007, 02:53 #6
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Because "dog implements animal" would sound quite stupid, won't it?
And what on the earth is "qanimal"?
gjones example is the best. Never write more code than needed to get it to work.
No, I'm not trying to inflame yet another "interfaces vs duck typing" holy war. I'd suggest forum search for "interface", the topic has been discussed far more than enough.
-
Jul 28, 2007, 04:10 #7
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
And that doesn't sound like a good reason to waste your one shot at inheritance. I recently did a grep over my source files to see how often I actually use the extends keyword and the only two scenarios that involved that keyword were when I was required to use it because of a third-party or when doing "interface <foo> extends <bar>"
And what on the earth is "qanimal"?
gjones example is the best. Never write more code than needed to get it to work.Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
-
Jul 28, 2007, 04:45 #8
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Even better:
PHP Code:class Cat {
function talk() {
echo "Meow";
}
}
class Dog {
function talk() {
echo "woof!";
}
}
class Interrogator {
function makeItTalk($subject) {
$subject->talk();
}
}
working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Jul 28, 2007, 08:06 #9
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It makes it easier to change the interface. If a method is declared private or protected, it's fairly easy to rename the method, because you have a limited number of places to look for. With a public method, you could potentially break any part of your application.
On the same note, I've found myself using typehints more recently - And as a consequence of that, interfaces (Since typehinting to a class is a hard coupling). Maybe it's just a phase I'm going through.
-
Jul 28, 2007, 13:43 #10
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> Maybe it's just a phase I'm going through.
Did you think at the time, your design will be more flexible because of this? Or do you precieve your design is more flexible Kyber?Last edited by Dr Livingston; Jul 29, 2007 at 06:42.
-
Jul 29, 2007, 07:11 #11
- Join Date
- Apr 2006
- Location
- Pennsylvania
- Posts
- 1,736
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I also feel more comfortable using type hinting, though it's probably my preference of strongly typed languages.
I just can't bear having a parameter that I plan to call a method on, and having no ensurance that that method actually exists in that object. For example if Talkative is explicitly hinted in the parameter of makeItTalk(), I can be sure that talk() exists. Otherwise any old object could be passed and I couldn't be sure if it implemented that method.
As for the way to implement this in PHP, it'd be the same as in Java I guess. Whether I would have a separate talkative interface depends if other things besides animals need to talk. Also whether I would have an animal class at all depends if I really ever care if it's an animal, or just ever want to know if it can talk or not.
If both the above are true then yes, I would have a Talkative interface implemented by an animal abstract class. That's maximum flexibility; but you need to be careful not to take that too far. It'd be pretty absurd to have a Walker interface for animals too, for example.
-
Jul 29, 2007, 08:33 #12
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
But of course you could!
What happens when you pass as a type-hinted parameter an object that doesn't comply with the type? You get a runtime error.
What happens if you call a method of an object which doesn't have that method? You get a runtime error.
My point is that the sense of security you get from type hinting is a false one, and that (at least in PHP) it doesn't add any benefits you don't have with duck typing.
-
Jul 29, 2007, 09:07 #13
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'd agree that you don't need insurance against calling a method which doesn't exist: just don't pass the wrong kinds of objects. If you did, you'd soon know all about it even without a hint.
Hints do one of two things: provide documentation or define metadata for introspection. The only time they are really essential is for the latter. Phemto, for example, uses type hints to fill dependencies.
If the aim is to write simple, elegant code it's very important not to make things more complicated than they need to be. Everything has to justify its place anything that isn't essential should be stripped away.working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Jul 29, 2007, 11:03 #14
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I don't think typehints makes the code more flexible. Perhaps even the opposite. The value, it's adding is clarity. When you write very composite code, where there are multiple objects working together to produce a result, it can be hard to follow, where each part plugs into. By using typehints, it becomes obvious how the puzzle should be assembled. There are other ways to accomplish this, but since there is language level support for typehints, it seems more appropriate to use, than a userland solution. This of course is the same argument, McGruff makes about dependency injection containers, but I think it applies to manual assembly as well as automatic.
-
Jul 29, 2007, 11:52 #15
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Umm...
> but since there is language level support for typehints, it seems more appropriate to
> use, than a userland solution.
This is how I looked at it when PHP5 was first launched; I didn't just want to develop with PHP but I wanted to support it as well. Since then though, I've grown accustomed to using type hints in near 99% of my scripts.
There are a few places where I don't use type hints, although it's not common, for example here,
PHP Code:// ...
public function validate( QDataspace_Interface $request, $logger ) { ...
PHP Code:// ...
public function push( $acceptable ) { ...
As to flexibility, I still think the flexibility is still there provided the underlying structure has been well thought out, using type hints.
-
Jul 30, 2007, 00:05 #16
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It depends on what you do with the object, though. If you pass it to a constructor and keep it in an instance variable, you won't get the error until later. So my rule of thumb is that type hints are somewhat more useful in constructors than in other methods. I also find that the more recently added type hinting for arrays is more useful than object type hints.
I don't use object type hints much. I did for a while, but found that they made refactoring harder even though I tried to use them sensibly.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Bookmarks