Object Oriented Programming in PHP
Section 1: Planning Our Framework
As was the case in PHP 4, and as has become dominant in PHP 5, Object Oriented approach to PHP programming can save you a great deal of time and, consequently money.
However, there are several things you have to consider when attempting to build an object oriented framework:
- How reusable will my code be?
- How will I store data I get from user interaction?
- What will happen to my server if I have 10 concurrent connections? 100 concurrent connections? More?
- How upgradable will my code be at a later date?
How Reusable Will My Code Be?
One of the best way to plan your code is to grab out general pieces of functionality into libraries.
In the framework we will build, several library files will be created and a core object class as well.
Lets look over some common tasks we're going to most likely need. Most likely we will want to store some data to the database. If we are planning to present any data, do any sort of searching on this data, and perform manipulation, we will need a database.
Next, we are most likely going to need to save the state of the site to the session. If a user logs in, or if there's a shopping cart, your data will be written to the session.
We also need a generic way to transfer information from web forms on the client side to our local servers. Some sort of generic form field naming convention and rendering libraries will be needed.
The final library we will need to make will contain any sort of specific graphic layouts for your site. This is important because if you want to emphasize code reusability, you don't want to have your presentation mixed in with your data logic. This is all too tempting in PHP because of the ease in which you can switch from HTML into PHP code.
We will be carefully creating each one of these library files throughout the course of this tutorial. One important thing to consider, however, is that we will be examining the code in terms of "learning as we go". So essentially we will be bouncing back and forth between library files and the core object file for our framework.
This will give you a full learning experience and understanding of the code because we will have the opportunity to solve problems as they are presented to us.
How will I store data I get from user interaction?
The whole point of a framework is to make common tasks all go through a similar set of functions and act seamlessly. Usually 90% of the things our site should have to do would be already coded into our framework. So this means after the first time of writing it, your sites will take 1/10 the time to code as they normally should have.
As we build our framework we must consider how we can structure our objects and library files to allow us to seamlessly take data from a user form to a database, or to the session, or to whatever other form of serialization we prefer.
What will happen to my server if I have 10 concurrent connections? 100 concurrent connections? More?
In the quest to make everything generic enough to make the site easy to program, developers are often met with the temptation to simply "load up everything" and only handle the pieces you need.
Clearly if you always have access to all possible data, you can make changes and access values with ease. However, attempting to join 10 tables in a database to perform one simple search can be wasteful and lead to the downfall of your site.
"Just throw more hardware at it" is never the right answer to this problem.
Instead, our framework will take a minimalist approach. We will always only load up as much data as is necessary to instantiate a functional core object. We will on top of this build a highly customizable caching mechanism which will attempt to take some weight off your database.
Many times it is not necessary to perform expensive hits to the database if you are performing the same query over and over again and the data never changes. Ideally we would want to have the option to "tune" our website and define when we want different levels of caching to occur and when we want to invalidate cache content. We will explore the pros and cons of this along with how to implement later on.
How upgradable will my code be at a later date?
One of the many benefits of PHP 4 and to a greater extent 5 is the ability of object inheritance. Combined with our approached to general utility libraries we will build a framework with enough generic pieces that upgrading will be considerably easier. With the focus on code reusability, upgrading code comes almost synonymously. If we upgrade the basic object with an enhanced bit of functionality, ultimately any object which inherits this base class will also reap the benefits of the new code.
For instance, if you give the ability for your base object to serialize itself to a text file, any object you inherit from this will also be able to serialize itself to a text file. We will also be examining this later on.
Now that we have gotten a brief overview of everything our framework will require, it is time to start diving into the code. First we will plan our most basic class and its interaction with the database, with web forms, and with the session.