So, when developing with symfony2, I rely on my tests. They are my safety net and without them, I get a little nervous after every change. Does everything work? Did I forget anything? So I developed some classes which I extend. They work on top of PHPUnit and the symfony2 WebTestCase. The classes are used by my different types of Tests: UnitTests, ValidationTests, FunctionalTests (as well as IntegrationTests).

Code for each type of testing base class is included in the post showing how he extends the based PHPUnit test case for unit testing and the Symfony WebTestCase for validation and functional testing. Each one of the classes are ready to use and give you some handy helper methods too.

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.

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).

I am finally starting to dive into symfony 2 properly. Yes - it's taken a while, work has taken me in different directions! I found myself needing to create a custom form field type pretty quickly, but couldn't find much in the way of documentation to do so, so I thought I'ld throw it up here; partly to help others, but mostly to get feedback to make sure I'm not approaching this from the wrong angle.

He includes the code that creates his custom "Person" model and the class to create his "transport type" select box that pulls in its values from a "choice list" class. He registers it in his bundle and it can then be included in his buildForm() method just like any other form field.

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).

In fact I think that using inheritance all the time is a very big mistake and makes your code hard to maintain and more hard to integrate (the latter is a mistake for application codes and a fatal mistake for libraries). The main problem with inheritance is that if you use it for coupling two classes, then a very important property of the subclass is used up: it's superclass. It is taken, reserved, and it can not be used for anything else furthermore. If you want to connect your subclass to an other class using inheritance, you can't.

He recommends avoiding the typical uses of typical superclass/subclass inheritance unless what you're doing specifically requires it. Working with interfaces, abstract classes and good composition planning is a much better idea.

Every class has an interface, every class can be typehinted as a method argument, typehint lets you specify the collaborator requirements. Not every typehint is the same.

He includes an example of how, despite a "BankAccount" type hint, classes for different types of accounts can be created and methods from the parent can be overwritten. To help remedy the situation, he shows a more structured example that uses interfaces/an abstract class to define the BankAccount structure, setting requirements on the child class functionality.

In object oriented programming, polymorphism is a powerful and fundamental tool. It can be used to create a more organic flow in your application. This tutorial will describe the general concept of polymorphism, and how it can easily be deployed in PHP.

He explains to concept of polymorphism for those that haven't seen it before - common interfaces to multiple objects - and how to can help make using the parts of your application much simpler. In his code examples he uses interfaces and abstract classes to make the connections. The interfaces define the structure to follow and the abstract classes are the multiple objects that must follow it.

Every once in a while I stumble upon interfaces or somebody mentions them to me. Whenever this happens I realise that the use of Interfaces as an OOP key feature in PHP is next to none at all. But why is that?

They note that, while interfaces are used all over projects in other languages, it seems like PHP development has steered away from their use. They define normal interfaces and abstract interfaces for those that don't know and talk about the differences between them. He also includes a brief code sample with description of its use and a bit about interfaces and frameworks.