The following types are allowed:

• Array
• Class names

Parameter type hints allow callable types, but until a keyword is assigned to “callable” (RFC), it’s not possible to implement this for method returns. To be honest, I’m not completely sold that it should be implemented at all. That’s another conversation.

The syntax is simple – rather than declaring “function”, you replace it with array or your class name. Since mixed types are allowed, you can still use “function”.

<?php
class MyClass
{
    public ArrayIterator getIterator() 
    {
        return new ArrayIterator();
    }
 
    public array getArray()
    {
        return array('I am returning an array');
    }
 
    public function thisStillWorks()
    {
        return 'This still works, too.';
    }
}

The same rules and errors for type hint parameters apply if you attempt to return a value not specified by the return type; a catchable fatal error will be thrown. Note that this is NOT an exception.

Reflection

I added “getReturnType()” to the ReflectionMethod class. It will return one of these three values: “mixed” – for function, “array” or “ClassName” if an object is specified.

Interfaces

Interface implementation is incomplete. I will be working on that this week. That said, if you specify an interface on the return type, it works just fine. The only thing not implemented is validation on overloading interface methods.

Interfaces and type hinting return values are fully implemented now. If, for example, you implement an interface which defines a method that returns an array, and you attempt to change it, an E_COMPILE_ERROR is raised.

<?php
interface MyInterface
{
    public function blah();
}
 
class YourClass implements MyInterface
{
    public function blah()
    {
        return 'works!';
    }
}
 
class MyClass
{
    public MyInterface getValue()
    {
        return new YourClass();
    }
}

The above works and validates correctly.

Help

If you’re interested in testing out this patch, shoot me an email using the contact page. If you’d just like to play with the functionality, go to my GutHub page and download or clone the repo. The branch I’m working out of is “returntype”. Just make sure you compile with –enable-debug.

If you happen to run into any memory leaks, please provide any information returned from the output.

Until next time.

As a company grows, it becomes a much bigger pain and seemingly less logical to maintain data in this manner. It requires more and bigger hardware, labor, decreases performance and becomes difficult to maintain and scale out. This can partly be blamed for the nature of relational systems.

Most RDBMS include the following high-level functions: querying, retrieving/writing data and replication. Each node acts on its own with identical or nearly identical copies of the data and, depending on whether the server is a slave, master or both, requires execution of the same query across the network in order to maintain the data. The query execution may come directly from the client or via replication from a master.

This is a relatively quick and easy start-up solution that requires less work as compared to a distributed system. The typical master-slave setup can, for the most part, be automated for new hardware. Just purchase similar hardware, increment the slave’s connection identifier, copy the data from another slave or snapshot and start it up.

To an extent, it’s also easy to scale. If you’re currently able to serve 2,000 queries per second, and your business grows to need 2,500, you simply add a new server. This is sufficient for many – probably most companies. But how about the need for 100,000, 300,000 or 2,000,000 queries per second? This is where the dwindling begins.

My rule of thumb is one master per four slaves at most – providing me with a 25% write-to-read ratio. Unfortunately, this also means I need some hefty, expensive hardware to do the job. A typical master for us at quepasa.com is dual, quad-core Xeons with 72GB of RAM. Since we are a heavy write-based system, we need fast disks; we also have a lot of data. In order to scale a solution like this, we have SANs in both data centers. Again, also very expensive. It works like a charm for now, but I’m constantly worried about what happens when we have 300,000 or more new users a day signing up. At what point does expense and maintenance start outweighing the benefit of this bulky hardware setup?

A few weeks ago I started research how DDMSs could work at our company. There were and still are many questions that I have to answer in this regard. What advantages and disadvantages will come with this new architecture? What hardware can I reuse efficiently with this new setup? What vendor do I choose to go with? What kind of code changes and culture shock will this introduce to the developers and DBAs?

Advantages

To begin with, this solution is extremely scalable. The general concept of a distributed database means expansion will be easier while not sacrificing reliability or availability. If I need to add more hardware, I should be able to pause a node or partition, copy it over and start the new hardware up (at a very high-level) without worrying about the rest of the system taking a massive beating and risking a crash or series of crashes.

Since this setup doesn’t require those massive machines we’re using right now, we can use commodity hardware that provides decent RAM (most of the expense of those bigger machines is here) and good CPUs. Off the top of my head, I imagine the hardware I’d consider for this would have four to eight GB of RAM and dual, quad-core Core i7s or possibly Xeons of the Westmere flavor. I definitely want to provide as many cores as I can to each node for higher throughput. This scenario likely means the bottleneck will now become the network itself. These nodes need to be able to communicate often, so a 10GbE network would eventually need to replace the 1 GbE. Speaking of which, I’ll move on to disadvantages.

Disadvantages

For our company, and probably all others in a similar scenario, the biggest disadvantage would be code and culture change. We’re used to writing code that connects to a database and executes a stored procedure that lives in the database and is written in SQL. Introducing this new architecture would completely change our environment. Stored procedures would likely be written in Java or another JIT language. The CRUD functionality would then execute that instead. This essentially means a rewrite of much of the site.

Building on that, we also introduce additional complexities into the architecture. This potentially means more cost in labor. Though the amount of time I put into weekend and late night/early morning maintenance renders that point moot.

We’ve also invested a lot of time and money into the hardware and architecture we have today. Introducing the concept of commodity hardware into the system could cause both economical and political backlashes. Fortunately, this likely appears more extreme than it really is. That bulky hardware could easily be sold at a decent price and the money from that used to purchase enough commodity hardware and then some. I’m not as worried about this aspect.

There are also solution-specific problems that are introduced. The concept of DDBMS itself is rather young and the lack of options and experience raises concern. This also means there’s a lack of standards to follow meaning moving to other solutions would be a major PIA at best. I would also be concerned with how the vendor treats concurrency control among the nodes. This is a major consideration in this type of environment.

While there are a few distributed solutions out there: Hadoop, Cassandra, Hypertable, Amazon SimpleDB, etc., one stands out in my opinion – VoltDB.

VoltDB is a next-generation SQL RDBMS with ACID for fast-scaling OLTP applications. It’s core is written in C++ and they provide many client connectors with Java the forefront. After looking into and reading more about them, I decided to query John Hugg (@johnhugg) for the potential of a PHP client. To my surprise, they already had one. John pointed me to the repository for the extension and I had a look at it. While John did an excellent job with the extension, it requires the use of a SWIG and it’s written in C++.

I asked John what he thought about a wrapper written in C and a pure C extension for PHP that is compiled against that library. It feels like a true “PHP solution” that could be added to PECL at some point and would eliminate the need for a SWIG. He was very excited about the potential for a more native solution.

That brings us to today. At this point, we’ve decided to research more into the potential for a C API. And once I get a better grasp on the core of VoltDB, I’ll be able to help John, et al. with a roadmap. The PHP extension will come after that.

I’m extremely excited about VoltDB and what opportunities it will bring to quepasa.com. I feel comfortable with the concept but skittish with the PHP integration. I’m confident that over the next year we’ll be able to come up with a good outcome and hopefully help others find their scaling solution in VoltDB.

If you’re interested in learning more about or helping with the C API and PHP extension efforts, visit the VoltDB community page and signup for the lists or leave a comment here. You can also download Volt and play with it in your own sandbox. It’s open source, so you can check out the core as well.

I will also be showing you how I manage MySQL upgrades and versions on my database machines. This includes keeping the previous version of software for emergency rollback. You never know when an unexpected bug or feature will cause problems for you, so it’s good to keep at least one historical version on hand. I highly suggest that you let the new version of MySQL burn-in for at least 48 hours before migrating the binaries and upgrading the rest of your boxes.

There have been cases where a version of MySQL that I’ve compiled has introduced problems. The majority of the time this is related to replication or collations. Whatever the case, I had the need to rollback to a version that was working fine. You can typically do this for minor upgrades (e.g. 5.1.51 to 5.1.50) with a relative confidence. That level of certainty does not apply to major and major-minor (5.0.x to 5.1.x or 4.x to 5.x).

In order to accomplish this, I keep all versions of MySQL in the same directory with at least one previous version. My versions are installed in /opt. The installation directory is always named mysql-[version]. For example, if I’m installing MySQL 5.1.52, the path to the installation will be /opt/mysql-5.1.52. This let’s me keep a lot of historical versions on hand while also installing and distributing new versions without stopping MySQL. The production version is a symbolic link to the full path of the installation. For example, if version 5.1.51 is the production version, my symbolic link would be created like this:

ln -s /opt/mysql-5.1.51 /opt/mysql

A listing of /opt would yield something like this:

drwxr-xr-x  4 root root 4096 Sep 20 20:52 ./
drwxr-xr-x 25 root root 4096 Sep 23 23:42 ../
lrwxrwxrwx  1 root root   17 Sep 20 20:36 mysql -> /opt/mysql-5.1.51/
drwxrwxr-x  9 root root 4096 Jul 23 21:40 mysql-5.1.50/
drwxrwxr-x  9 root root 4096 Sep 20 20:34 mysql-5.1.51/

Notice that the previous version, 5.1.50, still exists in the event I have to rollback. If this happens, I simply take the following actions:

• Stop the running MySQL instance
• Destroy the existing symbolic link
• Create a new symbolic link that points to the previous version
• Start MySQL via /opt/mysql/bin/mysqld_safe
• Verify the problem no longer exists

The same logic applies to upgrading, but rather than creating a symbolic link to the previous version, it gets pointed to the new.

Prior to actually configuring, compiling and installing the new version of MySQL, we need to set some flags for the C and C++ compilers. This is where much of the optimization will come into play. Keep in mind that this is not all-inclusive, and there’s likely more compiler optimizations you can make for your distribution and hardware.

CPU-specific Flags

Depending on whether you’re using Intel or AMD processors, you will have some different flags to set. In my case, I’m using dual Xeon 5460s. The flag I use is SSE4.1, which is labeled for Core i7, but is generically used for X5400/5500 CPUs as well.

If you’re using AMD, you will have a different list to choose from. The full list of CPU flags can be found here. The generic, x86_64 architecture flag for AMD is athlon64.

Passing these flags to the compiler is done with two Linux environmental variables: CFLAGS and CXXFLAGS. CFLAGS is for the C compiler while CXXFLAGS is for the C++.

Now that we have the CPU-specific flags worked out, let’s discuss additional optimization flags. One of the most important flags you’ll set is the optimization flag (-O). There are technically five levels of optimization, but I’ll discuss only three: -O1, O2 and O3. Each of these levels represents GCC’s attempt to optimize the code produced from the source files. I’ll briefly explain these:

• O1 – Level one optimizes common features that don’t require speed-space tradeoffs. The executable produced by this level is usually faster and smaller in size than with no optimization.
• O2 – Level two includes level one optimizations and many, many others. Generally speaking, this is the route to go with on most distributions.
• O3 – This includes all optimization possibilities. Be careful using this one as is produces a rather large executable. While in some cases this may produce faster code, it has had the opposite affect with me. The only way to truly know if you should choose level two or three is trial and error. Compile the same version of MySQL with both flags and test which is faster.

The other two are O0 or no optimization and Os optimizes to produce the smallest possible executable for systems constrained by memory and disk.

For a full list of features that are optimized by level, see this image.

The next flag is "pipe". Pipe directs GCC to take piped input and use RAM whenever possible rather than disk. In most cases, you won’t see a big performance gain from this, but we’re trying to achieve maximum results. Next we look at C++ flags.

There are two additional flags passed to the C++ compiler in conjunction with those mentioned above: no-exceptions and no-rtti.

The flag no-exceptions removes error handling as it relates to exceptions in the produced C++ code. MySQL actually recommends this flag in order to increase the stability of the produced executable.

Finally we come to no-rtti. The answer to this is simple: MySQL doesn’t use RTTI, so the result is a smaller and potentially faster executable.

Our CFLAGS and CXXFLAGS declaration will look like this for Intel:

CFLAGS="-O2 -msse4 -pipe" CXXFLAGS="${CFLAGS} -fno-exceptions -fno-rtti"

and this for generic AMD:

CFLAGS="-O2 --march=athlon64 -pipe" CXXFLAGS="${CFLAGS} -fno-exceptions -fno-rtti"

Go ahead and execute that in your shell, setting the environmental variables. If you’d like to test that they’re valid, issue the following commands:

echo $CFLAGS
echo $CXXFLAGS

Executing the Configure Script

The configure scripts works to produce a valid makefile. The makefile contains the instructions to compile, install and clean the MySQL distribution you’re working with. There are some important options to pass to this script that will produce a faster binary. Not all fall under this category, and I’ll discuss each option shown in the example below:

./configure \
  --prefix=/opt/mysql-5.1.52 \
  --enable-static \
  --with-charset=utf8 \
  --enable-thread-safe-client \
  --without-debug \
  --with-fast-mutexes \
  --enable-assembler \
  --with-plugins=innobase,partition

Prefix (–prefix) creates a variable that prefixes all installation directives. In the example above, we use /opt/mysql-5.1.52. This means that all executables, man pages, directories and scripts will be placed inside that specified directory.

Enable static (–enable-static) enables static linking to components. There is a trade-off with this. While it produces a faster executable, the footprint of the file is much larger. We will be able to dramatically reduce that later, however.

Setting the character set to UTF-8 (–with-charset=utf8) allows us to support multiple languages and characters outside of the default Latin character set. This is optional and by far not an optimization technique. It could easily be argued that this has the opposite affect, but if you plan to support a global audience, I’d suggest choosing this option.

Enabling a thread-safe client (–enable-thread-safe-client) produces the client software such as mysql, mysqladmin, mysqldump, etc. with thread-safe capabilities.

Disabling debugging (–without-debug) is an obvious performance booster. We most definitely don’t want MySQL to be worrying about providing that kind of information on a production system.

Fast mutexes (–enable-fast-mutexes) is another one of those trial and error situations. Depending on your machine, fast mutexes may or may not provide benefit. As with optimization level three, you will have to experiment to determine whether you should use this option.

Using an assembler (–enable-assembler) tells MySQL to use those versions of some string functions. This provides some optimization but not a lot.

You need to determine which plugins (–with-plugins) to use with your distribution. This is an application-level decision and the less you use the better off you are. InnoDB is the premier transactional engine for MySQL, so I’d highly suggest enabling and using it. The partition plugin allows you to scale your tables based on your defined criteria.

Now that we’ve prepped our software, it’s time to compile and install! This is my favorite part. I truly enjoy watching the makefile instruct GCC to chunk the source code and produce the fastest possible software. This makes me a super-dork, but it is what it is.

Execute the following command in your shell:

make

This starts the compilation of the software. Get up, stretch your legs and grab some coffee. This is going to take a while.

Once the compilation is complete, we’re ready to install the software. This is an easy one:

make install

List your /opt directory to ensure the software is good to go:

ls -al /opt

strip /opt/mysql-5.1.52/libexec/mysqld

You can also execute this on any binary file within your new distribution, but mysqld is certainly the most important.

Activating the New MySQL Version

Activating the new MySQL version is easy:

• Stop the running MySQL instance:

  /opt/mysql/bin/mysqladmin shutdown

• Destroy the existing symbolic link:

  rm /opt/mysql

• Create a new symbolic link that points to the new version:

  ln -s /opt/mysql-5.1.52 /opt/mysql

• Start MySQL via /opt/mysql/bin/mysqld_safe:

  /opt/mysql/bin/mysqld_safe --user=mysql &

There are additional optimization techniques you take use when configuring your MySQL instance (such as CPU priority), but I’ll save that for another entry.

As we countdown to the public beta release, I want to keep you informed of some exciting functionality that’s being added.

Functionality

Along with the JSON controller, a new XML controller has been added. This allows you to return nearly anything from an action and it will automatically convert it to XML, send the proper content-type header and provide the data to the client. Here is an example of how it would work:

<?php
 
class MyController extends \Fever\Controller\Action\AbstractXml
{
    public function getTestData()
    {
        return array
            (
            'name' => 'Will Fitch',
            'attributes' =>
                array(
                'height' => 76,
                'hair' => 'brown',
                'eyes' => 'brown'
                )
            );
    }
}

This will, in turn, produce the following XML document to the client:

<results>
    <name>Will Fitch</name>
    <attributes>
        <height>76</height>
        <hair>brown</hair>
        <eyes>brown</eyes>
    </attributes>
</results>

Now I’m sure there are those out there that are screaming, “But I want to customize the name of the elements!!!”. No problem! There is a method withing the AbstractXml controller called “setXmlElement” which accepts an instance of SimpleXMLElement. This will be used when converting data provided into XML.

This is all thanks to a new component called “XmlConverter” which lives in the \Fever\IO\Xml namespace. It follows the chain-of-command pattern and iterates until it finds the correct data type provided. Here are a list of converters available for iteration:

• ArrayToXml
• BooleanToXml
• NullToXml
• NumberToXml
• ObjectToXml
• StringToXml

All of these are separate entities, so they can be used independently.

I’ll continue to update throughout the upcoming days before the public beta!

The birth of a new MVC framework, like most others, is spawned by frustrations with the functionality of one or more other frameworks: too much emphasis on design theory, not enough in others, speed, flexibility… the list goes on. The Fever Framework is no different. In an attempt to find a happy medium with design theory, speed, flexibility and latest PHP functionality, this framework is targeted at many audiences from small, shared-hosting environments to enterprise-level web applications. That said, let me provide some goals I’ve kept in mind while developing the Fever Framework.

Some Goals

Design theory and flexibility

I have often wrestled among object-oriented design theory, development time and speed, not to mention optimization which is usually the 800 pound gorilla in the room. Developers deal with this all the time; trying to squeeze a few more days in to ensure the code looks as good as it behaves.

The Fever Framework implements many OOP design theories and MVC functions. However, in some cases, it specifically goes out of the way to provide an easier interface for developers. For example, let’s say you’re implementing a series of actions which return JSON encoded objects. In many frameworks, this is taken care of within the model, provided back to the controller and sent to the browser. In the Fever Framework, you have a few options:

Controller-level

<?php
class MyBlog extends \Fever\Controller\Json
{
 
    public function getPost($id)
    {
        $posts = new BlogPosts();
        return $blog->findByPrimaryKey($id);
    }
}

The above example is a controller which extends the Json controller. The “BlogPosts” class is a model which extends the \Fever\Db\ActiveRecord class. The “findByPrimaryKey” is a method provided within AR. Once the object is returned, the Json controller handles the JSON encoding and sending proper HTTP headers to the client.

Model-level

<?php
class BlogPosts extends \Fever\Db\ActiveRecord
{
 
    public function getBlogPost($id)
    {
        $post = parent::findByPrimaryKey($id);
        return $this->setData($post)->toJson();
    }
 
    public function __construct()
    {
        parent::__construct(array('db' => \MyApp\Db::getReadInstance()));
    }
}

This example returns the data already JSON encoded to the caller. It extends the ActiveRecord class, set’s the data via “setData” (provide in DataModel), and chains “toJson” to the request. This returns the JSON encoded string needed.

This is only two of many ways to achieve the above goal. Design theory and flexibility aren’t mutually exclusive, and flexibility is just as important as design.

Latest PHP functionality

As you’ve already noticed, I’ve incorporated namespaces into the framework. This is especially nice when editing inside an IDE and you can dive down into each namespace to find code (remember the frameworks that use hack namespace styles that make the class name 50+ characters long?). The naming convention is easy to read and makes sense!

Speed

The Fever Framework can be used as a set of libraries, but I’ve taken the liberty to assume you’ll be using autoloading. There is a provided class, Fever\Autoloader which takes care of the inclusion of files for classes/namespaces. Since FF is setup to so that each class falls under a directory based on it’s namespace, autoloading is fast and efficient! With that in mind, there is an important feature (some might argue) you should keep in mind.

Each class comes with a comment block that contains all of the file dependencies as require_once statements. If you so choose, you can remove the comment block and everything will be just fine. However, keep in mind that each require_once call makes a full file scan. This is extremely unoptimized!

When you get the code base , you’ll also notice that a printed stack trace will be relatively short. You won’t have 30 classes printed out that are abstracts of abstracts of abstracts of interfaces. Like I said before, design theory isn’t the most important feature!

Models

As a PHP developer, this is likely where you’ll spend most of your time. Like Zend Framework, Fever doesn’t come with a abstract model. It provides a subset of classes for you to decide to use. For example, if you’re working at the table level, you might choose to use Fever\Db\ActiveRecord, which provides most of the functionality of the Active Record pattern. If you are only using stored procedures, Fever\Db\Procedure might be your choice. But databases aren’t the only types of models. What if you’re working with a SOAP client? You could extend the Fever\Soap\Client, which provides functionality related to SOAP.

Modules

Module-based application development is included. If you choose to use this, you simply add a couple of lines of code to your global bootstrap. If not, do nothing!

Each module is allowed to have its own bootstrap. That means you can customize it as a separate application. You can also define how modules are recognized. If each module is a subdomain, you simply provide that match to the router, and it will recognize it. If it’s a subdirectory, do the same!

Views

To provide some options, the framework comes with both a standard PHP view type as well as Smarty. By default, the standard PHP type is used. This is easily changed within the bootstrap of your application, or even module. Each view type comes with a set of helpers as well.

How do I get the code?

The alpha review will start on February 19th. This will include developer code reviews and testing. This circle will be relatively small (10 – 20 developers) and will last one week. The public beta will begin on February 26th, and a download will be available here.

If you are interested in joining the alpha review, please email me at will[at]phpfever[dot]com or use the contact form.

Presenter Bios

Travis Black, Developer, Centre{source}
Travis Black is a software developer currently employed centre{source} interactive strategies. He has been developing web applications in php since 2004. After some experience developing in Ruby, using both the Rails and Merb frameworks, he spent a good deal of time attempting to find a php alternative. In the end, he found symfony, and fell in love. Travis and symfony were married last year and have lived together happily ever since.

Brent Shaffer, Developer, Centre{source}
Brent Shaffer is a symfony developer and architect at centre{source} interactive strategies. He graduated from Belmont University in 2008 with a degree in Commercial Music Technology and a minor in Computer Science. He has experience with the .NET framework, but has seen the light, and has been a symfony zealot ever since. He has also done some other cool stuff.

The meeting location will be announced next week once I work out the sponsorship details.

The ICommand Interface

interface ICommand
{
    /**
     * Run a command
     * @param string $command_type
     * @param args $args
     */
    public function onCommandCall($command_type, $args);
}

This simple interface provides a method for executing a call to initiate a bit of functionality. Along with the classes that execute the functionality, you’ll need a class to handle the chain. We’ll provide this class with another interface requiring the use of a method to add chains and execute commands:

interface ICommandBuilder
{
	/**
	 * Run a command
	 *
	 * @param string $command_type
	 * @param mixed $args
	 */
	public function runCommand($command_type, $args);
 
	/**
	 * Add a new command class
	 *
	 * @param mixed $commanding_class
	 */
	public function addCommand($commanding_class);
}

The two methods here are used for executing commands and adding new command classes. Let’s build the chain-of-command class.

class ChainBuilder implements ICommandBuilder
{
 
	private $_commands=array();
 
	public function runCommand($command_type, $args)
	{
		if (count($this->_commands) > 0)
		{
			foreach ($this->_commands as $class)
			{
				if ($class->onCommandCall($command_type, $args))
				{
					return;
				}
			}
		}
	}
 
	public function addCommand($commanding_class)
	{
		$this->_commands[] = $commanding_class;
		return $this;
	}
}

The class above provides a mechanism for chaining your requests. You add the necessary commands to execute, then pass requests to runCommand, which will loop through all of the commands until one successfully completes the action, or it exhausts all commands. Here you could add interface checks and throw the necessary exceptions for commands not found, etc.

Let’s add a couple of command implementations: email and stream.

class EmailCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'email')
		{
			// send an email with $args
			return true;
		}
		return false;
	}
}
 
class StreamCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'writeStream')
		{
			// Write the stream
			return true;
		}
		return false;
	}
}

These commands email a user and write to a stream. Now let’s use them!

$command = new ChainBuilder();
$command->addCommand(new StreamCommand())->addCommand(new EmailCommand());
$command->runCommand('email',array('email'=>'me@you.com'));
$command->runCommand('writeStream',array('content'=>'Hi, stream!'));

Conclusion

At first glance, the chain-of-command pattern may look like overhead. But on a large code base, this code be useful when making a lot of modifications, etc.

The Observer

<?php
interface IObserver
{
	/**
	 * Method called on event change
	 *
	 * @param mixed $sender
	 * @param mixed $args
	 */
	public function onChange($sender, $args);
}
?>

As you can see from above, the observer implements a single method called onChange. This method is executed when the observable class changes. The first parameter is typically the instance of the class changing and the second arguments relative to the change. Now let’s look at the IObservable interface:

The Observable Object

<?php
interface IObserverable
{
	/**
	 * Add an observer
	 *
	 * @param mixed $obj
	 */
	public function addObserver($obj);
}
?>

The observable class provides a method for one or more observers to be notified. The observable class needs to maintain a list of these observers and notify them when necessary. A common usage of this is a logging mechanism that needs to be notified when data is created, updated and deleted.

<?php
 
class UserLogging implements IObserver
{
 
	public function onChange($sender, $args)
	{
		// Log the changes (we echo here)
		echo 'The class is '.get_class($sender).' and the arguments are '.print_r($args,1);
	}
}
 
class User implements IObserverable
{
	private $_observers=array();
 
	private function notifyObservers($args)
	{
		for ($i=0, $count=count($this->_observers);
			 $i < $count; $i++)
		{
			$this->_observers[$i]->onChange($this, $args);
		}
	}
 
	public function deleteUser($id)
	{
		$db->deleteUser($id);
		$this->notifyObservers(array('user_id'=>$id));
	}
 
	public function addObserver($obj)
	{
		// Add logic for interface implementation check here if you want.
		$this->_observers[] = $obj;
	}
}
 
$user = new User();
$user->addObserver(new UserLogging());
$user->deleteUser(55);
?>

Not only does this provide you some pseudo event access, but this is a much cleaner, maintainable implementation of observing a particular object.

Conclusion

I hope you find ways at work to implement this use pattern. We more often than not get caught up with getting code written (it comes with the territory) and lose sight of these power and proven designs to get the job done. I’m certainly just as much to blame as the next developer! Hope this helps!