When we write programs, we may often get into a situation where we don't know whether we should use Abstract class or Interface when we want to define an abstract object. These two are very similar and they are interchangeable. On Stackoverflow, this question is asked many times, it's related to many programming languages. Also in the official documentation of PHP regarding the Abstract class and Interface, people are arguing about this. To understand this question, we need to understand their differences and use scenarios.

They provide examples of abstract class and interface usage with one of the main differences being that you can define functionality in abstract classes. There's also examples showing classes that extend the abstract class while implementing the interface at the same time, helping to define the object structure to an even finer level.

Features of object oriented languages are often use from a purely technical perspective, without respect to their actual semantics. This is fine as long as it works for you, but might lead to problems in the long run. In this article I discuss the semantical differences between abstract classes and interfaces. I also outline why following the semantics of those language constructs can lead to better code.

He defines "class" and "interface" before he gets too far into the differences, stating that a "class" is more of a "type" while an "interface" describes the type and the structure to use it. He also talks about how to tell them apart (when to use each). There's also some examples and "hints" to help you determine good and bad examples of interfaces and when an abstract class might be a better answer.

This bring us back to the question whether it's feasible to eliminate duplicated strategy logic via Inheritance rather than switching over to plain Composition. Indeed it is, and the clean up process can be conducted through an ubiquitous pattern known as Template Method. [...] Simply put, there's a base class (usually an abstract one), which declares a concrete method (a.k.a. the template) responsible for outlining the steps or hooks of a certain algorithm. Most of the time the base type provides boilerplate implementation for some of those steps and the remaining ones are delegated to subclasses.

The subtypes then override the base's functionality and extend it with their own. They show an example of this by making a jQuery image slider (using this plugin) , an "AbstractCycleSlider" class and two subclasses for two other types - "FadeSlider" and "ScrollSlider", each outputting their own HTML. It also shows how to implement a slider using a different plugin and output both in the same script.

In this article I'll show you how to exploit the virtues that Polymorphism offers through the development of a pluggable cache component. The core functionality can be expanded later to suit your needs through the development of additional cache drivers.

He starts off with the definition of an interface to provide structure to the sample application (the CacheInterface) and implements it in two different subtypes - a FileCache and an AppCache (using the file system and APC, respectively). He builds on these and creates a "View" that uses these caching systems to generate and save the output to a cache for use later in the execution.

Traits is a good new addition to PHP language. In our series about the new features of PHP 5.4, we reviewed the concept of Traits in PHP. The introductory article talks about what the traits are and what is the general syntax of Traits in PHP. The second article attempts to explain why we need traits.

The tutorial shows you how to define a custom trait use things like abstract methods, nesting them by making them "users" and how to use multiples at the same time (comma-separating).

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.