Every once in a while I discover a really cool, really underutilized component in PHP and I just have to write about it. I recently discovered (through my use of Zend Framework) the implementation of the ArrayObject class.
ArrayObject is an object that is designed to behave exactly like an array. If that seems confusing, don’t worry, it’s not. ArrayObject is an object. It follows all the rules of how objects work. But it’s designed to implicitly behave like an array for all intents and purposes, including being used in a foreach loop, and accessing it’s properties just like you would access the values in an array. Consider the following code sample:
Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval.
Much of the debate in the comments focused on whether or not the registry pattern was suitable for today’s object-oriented development, and some of the arguments focused on whether or not the “global scope” was a good place to have objects.
Last week I wrote about five tips to improve object-oriented code. This generated a number of important questions, which I will attempt to answer for those who asked them.
“Often times when a developer gives each object only one responsibility, they tightly couple objects together.” Can you explain?
There are two major pitfalls in object-oriented programming: trying to do too much with an object, and trying to couple a number of objects too closely together. For this example, we’ll use the engine metaphor.
There seem to be lots and lots of PHP folks out there looking to hire good PHP developers. Finding the right developer can be a challenge, as can finding the right job.
I’ve been looking for a couple weeks now, and I wanted to put together a short blurb on why you should consider hiring me to be on your PHP development team.
A little while ago, I wrote an article discussing why interfaces rock and the way that interfaces work. However, a couple of comments made me realize that I didn’t discuss one of the key elements about interfaces: why you would use them.
One key rule about interfaces is that all methods must be defined as public. You cannot define protected or private methods, and you cannot define any members of any type. You may define constants, as these cannot be overridden by any class implementing the interface.
With the introduction of PHP 5, the PHP Data Object was introduced as core functionality. PHP 5.1 turned on a minimum level of support for SQLite, by default, and PDO supports most of the major database engines. PDO offers a number of enhancements and improvements over the various database libraries (e.g. mysql_*, mysqli_*, pg_*), the biggest one being consistency. Still, the high level of code that involves direct use of the various database libraries means that PDO still isn’t as widely accepted as it should be.
This primer will show the various uses of PDO, and outline some of the benefits.