08.07.2007 / Object-oriented PHP :: A guide for fellow ISys junkies

Pages: 1 2 3 4 5 6 7 8

Interfaces

If you don’t remember what interfaces are, I’ll do my best to explain. Work with me here. Oddly enough, interfaces in programming have some similarities to interfaces in the real world. Take the buttons on my TV for example. Wait, no, take the buttons on my remote instead. You know I haven’t touched the buttons on the TV since I bought the thing. I need at minimum five buttons on my remote to ensure that I can enjoy the latest episodes of Mythbusters, Glenn Beck, and Cops: power button, channel up, channel down, volume up, and volume down. Sure, I’d love a TiVo with all it’s recording abilities, but I’m too cheap for that. Right now, the five buttons will do, but nothing less. Now, give me a remote for a different TV. As crazy as it is, I still have at least the five buttons that I need! Why? Because the manufacturer of the TV knows there are five operations that I have to have to qualify for my membership renewal in The Bedsore Club.

Interfaces in programming are similar. I have a class that can call the functions power(), channelUp(), channelDown(), volumeUp(), and volumeDown() of whatever class that you give me. I don’t know exactly what you’re going to do once I call those functions, but to make sure nothing breaks between my class and your class, I’m going to require that you expose those five functions: power(), channelUp(), channelDown(), volumeUp(), and volumeDown(). Here’s how:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// I declare the interface - notice there's no "class" word on the next line
interface Remote {
  public function power();
  public function channelUp();
  public function channelDown();
  public function volumeUp();
  public function volumeDown();
}
 
// You implement the interface
class SonyRemote implements Remote {
 
  public function power() {
    // Do something
  }
 
  public function channelUp() {
    // Do something
  }
 
  public function channelDown() {
    // Do something
  }
 
  public function volumeUp() {
    // Do something
  }
 
  public function volumeDown() {
    // Do something
  }
 
  public function record() {
    // Do something
  }
 
}
 
$myRemote = new SonyRemote();

To implement the interface, you just have to follow your implementing class name with implements and then the interface’s class name (class SonyRemote implements Remote {.) Remind you of Java? Also, as you can see, SonyRemote contains at least every method that is defined in the Remote interface. I also threw another method in the SonyRemote class just so you can see that you can and most likely will add other methods in addition to those defined by the interface. If you by chance don’t implement all the methods required by the interface, you’ll see this error:

[code]
Fatal error: Class SonyRemote contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Remote::power) in /mnt/backside/vol/navyblue/spunky/aaronius/aaronhardy.com/php_sandbox/index.php on line 73
[/code]

Before moving on, there are a few other things we can learn from interfaces. Interfaces themselves cannot be instantiated. In other words, if I try to instantiate the Remote interface like this:

1
$myRemote = new Remote();

I get this:

[code]
Fatal error: Cannot instantiate interface Remote in /mnt/backside/vol/navyblue/spunky/aaronius/aaronhardy.com/php_sandbox/index.php on line 75
[/code]

So, an interface is really just instruction to the programmer saying, hey, if you want me to use your class, it must have at least these functions. I then enforce that instruction by only accepting your classes if they have implemented the interface.

Another thing to know is that you can also enforce the number and types (see the section on type hinting) of arguments that the methods must have. Here’s an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Declare the interface
interface Remote {
  public function power(Dog $niner);
  public function channelUp();
  public function channelDown();
  public function volumeUp();
  public function volumeDown();
}
 
// Implement the interface
class SonyRemote implements Remote {
 
  public function power(Cat $niner) {
    // Do something
  }
 
  public function channelUp() {
    // Do something
  }
 
  public function channelDown() {
    // Do something
  }
 
  public function volumeUp() {
    // Do something
  }
 
  public function volumeDown() {
    // Do something
  }
 
}
 
$myRemote = new SonyRemote();

The interface says that my Power() method must accept a dog, but my SonyRemote class’s Power() function is accepting a cat instead. I have no idea what a dog and cat have to do with power, but anyway we would get this error:

[code]
Fatal error: Declaration of SonyRemote::power() must be compatible with that of Remote::power() in /mnt/backside/vol/navyblue/spunky/aaronius/aaronhardy.com/php_sandbox/index.php on line 58
[/code]

One last thing: you can implement multiple interfaces by separating the interface names with commas, like this:

1
class SonyRemote implements Remote, SomeOtherInterface

Easy enough. You’re well on your way.

Pages: 1 2 3 4 5 6 7 8

Tags: , ,


Comments

08.07.2007 / Michael Jackson said:

Nice site you have here Aaron! There’s just one small point that I think you might be interested in. You mentioned that PHP doesn’t support object overloading, but it actually does. Several special methods can be set up on objects, including __get, __set, and __call. This may not be the same implementation as is found in other languages, but it is overloading. Check it out.

08.08.2007 / Aaron Hardy said:

Hey Michael, thanks for joining the intimate conversation! I guess I should have been more clear on my explanation (which I’ve since changed), but I’ve always thought PHP’s attempt at supporting method overloading is pretty weak sauce–more of a hack then true, native overloading as found in other languages (like you noted.) So when I said there are hacks to support the functionality, I guess I just grouped PHP’s way of overloading in with it.

For those of you who may be interested in the functionality Michael’s talking about, here’s PHP’s documentation on overloading.

In any case, it’d probably be fair to remove overloading from my “not supported” list and actually dedicate a section to explaining how it is (kind of) supported in PHP. Thanks for bringing up the issue! I hope you enjoy the rest of the article!

08.08.2007 / Scott said:

Hi Aaron, you did this tutorial just in time for me! I decided to teach myself PHP and good tutorials on using patterns and OOP in PHP is hard to find. I do want to point out that in Intex DAO’s were not static classes, we used the singleton pattern to instantiate a DAO once and then passed a reference to the DAO around. Though I’ve found tutorials on the web showing ways of implementing the singleton pattern in PHP, I cannot find anyone addressing the issue of how to make sure a object is only created once given that in PHP you cannot use “synchronized” key word to insure that a function isn’t called multiple times at the exact same time.

Also, and more important to me, I would like to understand how to create objects and classes that are instantiated and then used across all sessions. for example, if I create a class that has a static variable called “$counter” that starts and 0 and gets incremented every time a function in the class is called, the first time a page is loaded, the counter will increment to 1, the next time a the page is loaded, the object appears to be destroyed and recreated thus the counter is reset to 0 and will never be incremented past 1. Is it possible to create objects in PHP that can be passed around to all sessions that may be connected to the server?

08.08.2007 / Aaron Hardy said:

Hey Scott!! Thanks for joining…the intimate conversation. I’m glad I could be of service, if only a little. You’ve got some really good questions and I’m glad you posted them here publicly, because I’m not much of an authoritative source when it comes to the PHP core engine. With that in mind, I’ll do my best to provide insight where I can.

First off, I guess I completely forgot that we were using the singleton pattern for our DAOs during INTEX II! In any case, I don’t see much of an advantage to using the singleton pattern over static methods in this case. I’d still choose the static methods over the singleton pattern, but I’d love to hear some rebuttal from someone as to why I shouldn’t.

Okay, onto the stuff you were pondering. I think most of your difficulties in finding what you’re looking for is due to the difference in how PHP runs on the server compared to other frameworks like Java or .NET. With Java, you wrote your code and then you had to manually (by clicking a button, likely) compile it before opening it up in a browser for the first time. Then, you never had to re-compile your code until you had some code change that you wanted to take effect on the website. On the other hand, PHP is different. In the simplest of explanations, a PHP page is re-compiled each time it is called by a user. That’s why you don’t have to hit any compile button in your IDE when you want to check out the new changes you’ve made. There are some exceptions where you can actually compile PHP as a long-term executable or you can cache your pages, but again, my explanation is a simplistic one and I can’t elaborate much on the exceptions.

Also, Java can be very thread-based whereas PHP…not so much. Although there are web server environments that are threaded, PHP’s support is fairly limited. In fact, you’ll find a lot of articles where people say that the PHP development team recommends that you don’t run PHP on Apache 2 in multi-threaded mode, but I have yet to see the original source of that statement.

So, taking the differences into consideration, there is no “synchronized” keyword in PHP because there are no threads to synchronize. The same goes for using objects across all sessions. One of the noted benefits of PHP is that everything in memory is cleaned up after each session. There are no “application variables” (as they’re called in ASP) where you can set up a variable that exists over multiple sessions.

This doesn’t mean there aren’t ways to implement functionality similar to what you’re looking for though. PHP has the session_set_save_handler() method that can help save a user’s session to a database or file. You can read about it here:

session_set_save_handler() documentation

Here’s an implementation without using the session_set_save_handler() function:

Application variables in PHP

And if you’re interested in hacking up some threading in PHP, here’s an example:

Multi-threaded PHP

Needless to say, none of these options are super-duper pretty, but that’s not really PHP’s niche.

Anyone else want to comment? Please, I invite you to join….the intimate conversation.

08.09.2007 / Andrew Hegerhorst said:

Way to go on the tutorial, Aaron. For us php noobs it’s a keeper! I was reading through it and had a question, so I thought I would throw it out. Sadly, this will demonstrate exactly how new to php I am. ;)
Here’s the question:

Do you have any thoughts as to when the require function should be used as opposed to the include function? I have read about it a little, but being new to php I would appreciate any thoughts you may have on the subject.

Again, great job on the tutorial…

08.10.2007 / Fernando Mladineo said:

Hey Aaron,

Just started reading your PHP tutorial and I’m already learning new things. I just wanted to point out that you made reference to sayHello() on page 2 instead of sayWoot(). Keep up the good work!

08.10.2007 / Aaron Hardy said:

Hey Andrew and Fernando! I do appreciate you all joining…the intimate conversation! Let’s see what we can do here…

Andrew, when it comes to the difference between include() and require(), you can’t get much better than what PHP’s documentation has to say about it, so I’ll just copy it in here:

“require() and include() are identical in every way except how they handle failure. They both produce a Warning, but require() results in a Fatal Error. In other words, don’t hesitate to use require() if you want a missing file to halt processing of the page. include() does not behave this way, the script will continue regardless.”

Here’s the reference: Documentation on require()

Another thing to add to that is your server may react to warnings and fatal errors differently than another server, depending on your PHP configuration. If you want to see how it works on your particular server, try this example (make sure test.php does NOT exist):

include(”test.php”);
echo “Am I still processing?”;

Then try this one (again, test.php shouldn’t exist):

include(”test.php”);
echo “Am I still processing?”;
?>

And, although you may have already figured it out, include_once() and require_once() check to see if the file was loaded before. If it was, then it ignores the command and doesn’t load the file again. Personally, out of the four options (include(), include_once(), require(), and require_once()) I always choose require_once(). Hope that helps!

Fernando, thanks for the heads up! I’ve made the corrections. Three of them in fact. After writing the article, I thought I’d be a little more creative than the usual HelloWorld, but apparently I let a few slip through the cracks. Enjoy!

05.24.2008 / Dave said:

Just wanted to tell you that you did a great job in laying out this PHP tutorial.
I’ve picked up quite a handful of good tips by reading it.
just wanted to let you know that somebody out there thought this was quite handy!
later


Leave a Comment

Your email address is required but will not be published.




Comment


Warning: stristr() [function.stristr]: Empty delimiter in /home/.navyblue/aaronius/aaronhardy.com/wp-content/plugins/wassup/wassup.php on line 2093