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

08.07.2007

Pages: 1 2 3 4 5 6 7 8

I’m currently studying Information Systems at Brigham Young University where the main language being taught to students is Java, a very object-oriented language. Some students, after having learned Java, have difficulty making the jump from Java to PHP for one reason or another. While I do not profess to have reached the level of Zen Master in PHP, I do hope I can provide some insight in a way that fellow ISys junkies can take what they’ve learned and pick up PHP if they want. As always, I’m open to improvements/corrections in my code, questions, complaints, I-could-do-it-better-than-yous, whatever. So here we go!

First off, PHP has not always been an object-oriented language and has yet to become a “pure” object-oriented language (and probably won’t ever be–it’s good at filling a distinct niche somewhere between scripting and enterprise application development). For example, you can still code in PHP without using objects at all. Also, some object-oriented features that are available in other languages are still not available in PHP, like overloading (although supported, it’s not implemented the “standard” way we’re used to in other languages) and namespaces. There are hacks that can allow for such functionality, but we’ll leave those alone for now. In any case, PHP is still my friend and it can be yours too.

Before we get into the OO (object-oriented) code, I want to give a really short intro to a few PHP basics. If you’ve already played with PHP, you’re probably safe to move onto the next page.

Defining a variable

In PHP, a variable is defined the following way:

1

$myVar = "my string";

Notice I did not have to declare $myVar as a string before setting its value. If you were to then set $myVar = 6, no conversion code on your part would be necessary; PHP would convert it from a string to an integer for you. That’s one of the beauties and the uglies of PHP, take it or leave it. Every variable name must be preceded with a dollar sign (we’ll see somewhat of an exception on the next page.) PHP is also case-sensitive, so be sure you take care of capitalization.

Outputting to the browser
To output something on the user’s browser, use the echo command:

1
2

echo "A test.";
echo $myVar;

The first line prints A test. while the second line prints whatever is stored in your $myVar variable.

Concatenation and variable interpretation

Because we precede every variable name with a dollar sign, PHP can easily tell what’s a variable and what’s not. Let’s look at some code:

1
2
3
4
5

$name = "John Doe";
echo "Hello, $name!  Welcome to my website.<br />";
echo "Hello, " . $name . "! Welcome to my website.<br />";
echo 'Hello, $name! Welcome to my website.<br />';
echo 'Hello, ' . $name . '! Welcome to my website.<br />';

This outputs the following:

Hello, John Doe! Welcome to my website.
Hello, John Doe! Welcome to my website.
Hello, $name! Welcome to my website.
Hello, John Doe! Welcome to my website.

In our code, using double-quotes tells PHP to interpret our variables and spit out their values. On the other hand, using single-quotes tells PHP not to interpret variables, which is why our third output line came out the way it did. Finally, using a period (.) lets you concatenate the same way that you would using the plus sign (+) in Java. Usually we’ll want to use our first method unless there’s a compelling reason not to.

Now to the fun stuff…

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 commenting! 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 commenting. 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?

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 commenting! 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

05.26.2010 / Derek Christensen said:

You sent this link to the list again and I finally got around to reading it. Excellent introduction. I’ve been working with Drupal, which is PHP-heavy, and this helped point me in the right direction. Thanks!

05.26.2010 / Aaron Hardy said:

Thank you for thanking me. Glad it helped.

Leave a Comment

Your email address is required but will not be published.




Comment