January 15th, 2007 - by cpradio

I scoured the Internet for the past few days to see how many applications are actively writing their PHP code in an OOP (Object Oriented Programming) fashion and the results are surprising. I have found that many existing applications are not taking advantage of this ability that began its’ existence in PHP 4, which then spread its’ wings like an eagle and soared in PHP 5. I have been working on converting one of my largest projects in PHP from a style that is FAR from OOP to an architecture completely based on OOP and this experience has been very helpful and challenging and primarily based on my .NET experience with OOP.

See in PHP 4, everything was fairly easy to organize so long as you created functions for the tasks you did repeatedly, which is also known as “refactoring”. You can say the same concept holds true in an OOP environment, but it is also different. It is different in the sense you have to classify the functionality enough to associate it with a class. One could argue you could still write a function, but I decided to go 100% OOP and stray away from functions just for the shear challenge, be it right or wrong.

The first challenge I found myself occupied with was the number of classes I would potentially need. For my projects I came up with a few obvious ones, such as, a Session class, Database class, Design class, and an Error class. The next challenge I had to think about was how to setup each class. Should they be made of static properties/functions/methods (take your pick), or should it be an object that requires being Instantiated (meaning, you have to create an instance of the object before you can call any of its properties/functions/methods)?

This posed a serious question regarding PHP and how it handles static objects. See at work we use .NET and primarily code in C#. .NET is considered to be extremely OOP, and that is primarily because of how you are to develop in it. Every page you make is a class, and all refactoring you do will be in another class. However, when you work with static objects in .NET only ONE of those objects exist on each server your application is running. This can become havoc in a multi-threaded environment. If your static method isn’t fast enough, you may lock out another process because the prior one isn’t finished yet. So it is no wonder I came to the question of whether or not this holds true to PHP.

The answer is ‘Yes’ and ‘No’, I think. See in .NET this issue holds true because the code is already compiled and the ASP.NET handler caches the compiled version and keeps the static object in memory until the Garbage Collector deems it unworthy and tosses it out. In PHP, the code is compiled when requested, so would this mean each thread has its own static methods? Why yes it would, so how can the answer be both ‘Yes’ and ‘No’? Well, I answered ‘Yes’ as well as you have to take into account the other aspects of the server. Whose to say that PHP like .NET after compiling the static object decides to keep it in memory instead of destroying it with the non-static objects? No one. And I have yet to find any documentation that provides me with a solid answer one way or another. So, I answer the question as ‘Yes’ and ‘No’, but how did this help my decision process? It didn’t.

My decision was still tough and I just decided I would take the approach of using both static and non-static objects. The Database, Design, and Error classes would be static, as I could careless if the object is shared across all threads (requests) or just each individual thread. Think of it this way, if it is shared across all threads then the Design will be caught in memory and load that much faster for User #2-#5 as the hard work was done by User #1. The Database connection is not going to change between each request either, so I loseWeight Exercise nothing by that being shared either, and as for the Error class, this is for server errors, such as, failure to connect to the database or maybe an outside resource the application is using is not being responsive and will cause the application to not function properly. All of these can work in an environment where the information is shared across each request (like .NET) or if each request had its’ own individual static object.

So why leave the Session class as non-static? The session class is supposed to be unique for each request. Each user will have his/her own Session object. It is a collection of information, such as, the User Account they used to login, or their Checkout Details if used for a Store. This information should NEVER be shared across requests. Hence, it is a instantiated object.

I have received several questions as to why I created a Session class to begin with, and it again goes back to wanting to write a fully OOP application based on my .NET experience. See PHP 5, PHP 4, and PHP 3 have this nice function called “serialize” and its’ opposite “unserialize”. This allows me to create an object of any type with however number of variables I want and turn it into a string representation. Likewise, after it has been serialized, you can return it back to the object type using the “unserialize” function.

A part of me has to attribute this to what I have learned at work, as that is where this initial idea came about. Why force the language to have to read the header three or four times to get three or four session variables individually, if you can request the entire set of data once and unserialize it back into an instantiated object? Speed wise, depending how much information you keep in session, you could be saving a lot of system resources. Likewise, you could be wasting a lot of your time as I speculate PHP does this for you. The $_SESSION variable is an array of information and I am certain it serializes that array into the browser header for you and unserializes it back out, so is there a reason to do it again? Probably not, but if PHP does not automatically do this, then the benefits are of great value to serialize an object and store it in a single $_SESSION variable.

After defining my base classes, I quickly noted that these could be used in any project, so it would be AWESOME if I could reuse them in every project I make, but not have to copy them. For this I do not have a solution yet. Partially because every application you deploy, or allow others to download, will need these files and thus it makes more sense to store them with each project. The point here, is if your project is for internal use only (meaning your own application and will not be distributed), then by all means, store the shareable files in a directory that your other projects can take advantage of. Therefore you do not have to create copies of your database connection class, or similar classes you may need. Since my project is distributed freely, I have to make copies of these files to use in this particular application.

In Conclusion…
So as you can see, designing an OOP application, be it in PHP or .NET, requires making important decisions right at the beginning. Determining the right time to use static methods vs non-static is crucial and there are right and wrong times for both. Likewise, keeping in mind the deployment process of your application will determine where you store your files that can be reused. If it is for internal only, then by all means, do not store them with a particular project, make them more accessible at a root level, however, if your application will be downloaded freely over the Internet, then your best choice is to store a copy of each file with each project you make.

Keep an eye out for my next writing as I will go into more detail on each of my four primary classes and how I made them so they would work with any project I design in the future.

7 Responses to “OOP in PHP from a .NET OOP Perspective”

1 Introducing Matt Wilkin - aka cpradio

[…] Look for Matt’s, or rather cpradio’s first article this Monday titled: “OOP in PHP from a .NET OOP Perspective” – should be a good read. […]

[…] Home » OOP in PHP from a .NET OOP Perspective: The Database Class February 6th, 2007 For those just joining, it is suggested that you begin with OOP in PHP from a .NET OOP Perspective as this is Part 3 of a series. This time I am going to talk about the Database class, as every project now-a-days typically stores their information in a database. A good database class can save you time and memory in retrieving results. It should be able to cache previous queries, to recall them later, and it should clear out the results from memory when they are no longer needed. As with previous articles, it should be stated that the below code will only work using PHP 5. In this article, I am going to post my code first and then give a break down of the important segments. Again, this is my take on solving a problem for my applications and I am sure there are other approaches, but this is the one I am most please with. PLAIN TEXTPHP: class Database […]

3 Sam

Hi, i just stumbled across your posting and I read your profile too. You sound like a cool guy, I have also wanted to be a software developer. I have just always wanted to code and as of late last year I got a job programming in PHP and I know it, but I still feel like I don’t really know it. Basically, I’m happy to see you posting on such things and I can’t wait to read more…Thx again

4 zoid

Another great read, i was having a paradox between PHP and .NET and finally switched to .NET.

5 Peter Mansen

What do you think about UML, PHP and OOP?
The UML can help you to write easy the OOP classes.

6 Best of Search-This 2007

[…] OOP in PHP from a .NET OOP Perspective […]

7 Mike

“…if your static method isn’t fast enough, you may lock out another process because the prior one isn’t finished yet”

I simply do not agree with this assessment. I’ve been using static _methods_ / classes for domain services for quite a while with absolutely zero impact on the multithreading ability of the class (nANT verified). Now, if a static method is accessing some shared resource and locking access to it, then yes, that will definitely hold up other callers (by design). But this is not a problem unique to static methods by themselves.

Now, static _data_ on the other hand, is a different story, requiring all the goodness of locking/synchronization/etc., and also having all the pains associated.

Also, me thinks the Zend folks may also take issue with your assessment of how _SESSION works in PHP:

“The $_SESSION variable is an array of information and I am certain it serializes that array into the browser header for you and unserializes it back out”

The actual values in the _SESSION array are kept on the server-side; only the session ID is sent as a cookie (PHPSessID). Sending the actual data in a header would be a terrible security risk.

mulberry sale spyder womens jacket cheap new balance 574 mulberry outlet cheap new balance 574 arcteryx outlet mulberry sale spyder womens jacket mulberry sale spyder womens jacket mulberry outlet mulberry outlet new balance 574

Popular Articles

Top 10 Commentators

Subscribe to this feed! Subscribe by Email!

Random Bits Podcast

Blogs Worth Reading