DevShed has a new tutorial posted today looking to help you counteract the bad practice of wrapping procedural code in "class" constructs and provide some useful suggestions of how to avoid it.

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.

On DevShed.com today there's the first part of a two-part series showing how to build self-contained validator objects that can be used to test the format of user input for validity.

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.

On the XpertDeveloper.com site today there's a new tutorial talking about something that can not only help the structure of your application but can make things more reusable in the end - abstract 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).

Ian Christian has added a new post to his blog today showing how you can create a custom form field type in Symfony 2 by extending the AbstractType.

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.

In his latest article comparing some of the functionality of PHP to Ruby, Dave Kennedy looks at modules, mixins and ducks and how they compare to PHP's interfaces and abstract classes.

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 this new post to his blog, Bence looks at how inheritance is commonly used in PHP applications and how, if not controlled carefully can be something that creates bad habits among PHP developers.

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.

On the OpenSky blog today there's a new post about object oriented development and class structure. More specifically about how you should use interfaces and abstract classes if you want to truly lock down the methods of your classes.

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.

On the NETTUTS.com site today there's a new tutorial by Steve Guidetti about understanding and handling polymorphism in PHP - making interfaces to multiple objects that all work the same way. In this tutorial he gets more in depth and includes some code to illustrate.

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.

In a new post to the test.icial.ly blog today Christian looks at interfaces in PHP and why they seem to be ignored in a lot of the development work being done.

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.

Gonzalo Ayuso came across a situation where he needed to create a factory method inside of multiple classes but didn't want to have to create them each time. With class inheritance there had to be another way.

I have built a backend library. I have a tree of classes and i want to use singleton and factory patterns to my class set. Easy isn't it? [...] Now imagine you have a lot of classes. You must create over and over the factory function in every classes.

An abstract class is a perfect fit for this sort of thing, but there's not a good way to return the correct kind of object back from the factory method. That is, until you do some magic with a PHP installation version 5.3 and higher. With the get_called_class function, you can easily figure out where the request came from and return a correct object instance with one line.