There's been a lot of buzz surrounding the use of frameworks for quite a while now and there are many great PHP frameworks to choose from. I was blown away by the simplicity and power of the base CComponent class in the Yii framework. [...] Every class in the framework extends from the CComponent class, which means that all subclasses work as components and can raise and handle events as well as be reusable and configurable. This packs a lot of punch for such a little class!

In this first post of the series, he looks at how this base class lets you work with class properties using the magic getters and setters. He includes some code showing how to set them up and how to use it to configure your object by passing in other component and their configuration.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

In this two-part tutorial, I show why the use of static helper classes can be detrimental to building robust and scalable object-oriented applications in PHP (though you should take into account that the concept is language agnostic). I also implement a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Their set of "concrete validators" are all based off of a validator interface/abstract class and check things like email formatting, floats, integers and URLs. Also included are a few examples of using the validators in a sample script.

We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was... Interesting...

He shares some of the C code he came across in his investigation including a "WTF" moment when he found a case statement for DIT_IteratorIterator in a constructor. Because of some of the logic in this constructor, the inputted iterator is "cast down" to a class. This is shown in a few code examples comparing simple iteration objects and arrays and how it seems to be able to bypass class inheritance to use methods from other classes.

For Abstact keyword we can say that, abstract is type of the class and class which we can't create a object of it. Surprised???? [...] Abstract class can be used some what like an interface in PHP. So basically we can implement class using abstract. We can't extend more than one abstract class while we can implement more than one interface.

They introduce you to the creation of an abstract class and show how to set up some abstract methods inside. These methods are required to be defined as a part of the extension in your class. One of the benefits they don't mention of abstract classes over interfaces is the ability to have methods in the abstract that are actual code, not just definitions of the structure (that's more of what interfaces are for).

In the last post we had a simple stepping algorithm, and a gradient descent implementation, for fitting a line to a set of points with one variable and one 'outcome'. As I mentioned though, it's fairly straightforward to extend that to multiple variables, and even to curves, rather than just straight lines. For this example I've reorganised the code slightly into a class to make life a little easier, but the main changes are just the hypothesis and learn functions.

He restructures the learning method to make it easier to reuse and includes a "scale data" method to compensate for irregularities in the data and compute the variance.

Today I have another interesting article for PHP. We will talking about caching, and practice of using caching in php. I will make review of APC caching and will show you how you can use APC in PHP. [...] Now people have learned to use the server memory for data storage. RAM much faster than hard disk, and the price of memory falls all the time, so let's use all these advantages of this.

Included in the post is the code for a few different files - the caching class itself that implements the APC functions in PHP and some examples of it in use: saving objects, fetching data from the cache and removing things from the cache.

If you have been writing PHP for a few years you will no doubt have come across Interfaces and Abstract classes. They were introduced in PHP5 object model and since have had medium usage in the PHP world. If you Google "PHP Interfaces" you will get some results on the official documentation and the rest saying how pointless they are. Why the divide? I believe it is mainly down to lack of understanding to what interfaces give you. They imply what your classes should do, but that's it. Yep, we are talking programming contracts.

He starts with some code examples of an interface and a class that implements it (to work with PDFs). He makes an abstract class to extend the functionality even further and allow for different kinds of reporting PDFs to be generated. From there he moves into the Ruby world, showing examples of duck typing and modules to avoid duplication (mixins).

Last week I was thinking about creation of a new type of classes. PHP classes but created dynamically at run time. When this idea was running through my head I read the following article and I wanted to write something similar. Warning: Probably that it is something totally useless, but I wanted to create a working prototype (and it was fun to do it).

His class is pretty basic - a "Human" object that echoes a "hello world" sort of message via a "hello()" method. He creates the classes inside of different test methods to ensure that his assertions are true. The tests check basic output of the "hello()" method, calling undefined methods, testing inheritance and a test creating and evaluating a dynamic function.

For something more complex, he creates a dynamic class that solves the FizzBuzz kat, a popular programming puzzle. You can find the full code for this and his other examples on github.

If you create classes in PHP then you should be unit testing them as much as you can. Setting up unit testing classes for your code can be time consuming and involve a bunch of copying and pasting. Thankfully, PHPUnit comes with a couple of helper functions that allow the creation of unit testing classes automatically, which can save a bit of copying and pasting.

He includes an example of a class named "Spider" and shows both the contents of the class and the resulting test that comes from running "phpunit --skeleton-test" on it. The resulting test has methods for each method in your class and marks them all as incomplete. As Philip notes, this is a good start but should never be relied upon as a test to leave as-is.