On the Pixelstech.com site today there's a new post that talks about the differences between abstract classes and interfaces and when's the best time to use either (or both).

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.

On NetTuts.com today there's a new tutorial posted about "taming" Slim 2.0, the latest version of the popular PHP microframework. They look at application structure and share some tips to using this update.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that's not to say that Slim doesn't has some issues; it's one-file setup becomes cluttered as your application grows. In this article, we'll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

On PHP.net today they've announced the tagging and release of the latest alpha for the PHP 5.5.0 series - PHP 5.5.0 alpha4:

The PHP development team announces the release of PHP 5.5.0alpha4. This release fixe some bugs from alpha3 and add some new features. All users of PHP are encouraged to test this version carefully, and report any bugs in the bug tracking system.

There's new improvements included in this non-production release including class name resolution with "class" keyword and the DateTimeImmutable class. You can see the NEWS file for the complete list of changes. If you'd like to help test it out, you can download the preview release here (or here for Windows users).

Simon Jodet has a new post to his site for the Mockery users out there (a mocking tool used in unit testing) showing how he created his partial object mocks.

I really like atoum and highly recommend it. However, because it's a young project, I have two problems with it: The documentation was really lagging but it's getting there and integration with other tools is poor. [...] And then I stumbled on Mockery. Unlike atoum, it doesn't replace PHPUnit, it just replaces its mocking system with a more elegant, powerful and reliable one. The big plus of Mockery over PHPUnit is that you don't need to have the class to mock to create a mock. [...] But writing partial mocks with Mockery is not obvious.

He illustrates with a "Database" class example containing four methods, only three of which he wants to mock out - dropTable, listTables and getSchema. The fourth method, "reset", is then called directly and the mocked methods are used inside that. The database connection mock is then injected into the Database mock and the test is run. Complete code examples are provided.

In another of his series looking "under the covers" at what actually happens in the PHP language during its use, Sharif Ramadan has posted this look at the object handling in PHP's OOP functionality.

I would love to take a good long look under the hood at just how PHP objects and classes do the work that they do, and hope that you could benefit from that knowledge. [There are] many questions that come across my desk, on a regular basis, from developers and beginner PHP enthusiasts that I've worked with over the years, and are some of the key points this article attempts to help you answer.

He talks about classes "giving birth" to objects, how they're stored internal to PHP and how they provide the "blueprints" for it to lay out the storage of the object's data. He talks about using identifiers for variable/property access, object handlers and how "$this" fits into all of it. He notes that OOP, while a major part of PHP now, wasn't in the initial versions (until around PHP4). He finishes off the post talking about lateral/vertical context switching, the lifecycle of an object and the "early binding problem" and class scope.

In this recent post to his site Derick Rethans mentions the shiny new "MongoClient" class that the latest release of the Mongo PHP drivers provides.

This afternoon we published version 1.3.0 of the MongoDB PHP driver. Besides a number of bug fixes since RC2 and RC3, this new release also includes a new MongoClient class. This new MongoClient class serves as a replacement for the Mongo class. The old Mongo class is now deprecated and will be removed in a future release, although we are keeping it in place for now because of backwards compatibility reasons. We have already removed it mostly from the documentation, and are working to update all our other material as well.

The main change that comes with the MongoClient class is that it now has acknowledged writes on by default (a "safe mode"). This option determines wether or not the client waits for a confirmation from the server when a write has happened. He includes a bit of code showing how to: turn it off, keep it on or using replica set acknowledged writes. You can also set it on a per-query basis.

In the latest post to his site Andrew Podner takes a quick look at something you don't see too much in PHP applications but is a familiar concept to some coming in to the language from others - using "final" to prevent overrides of the code in your classes.

In a previous post about inheritance, I showed you how to extend a class. One aspect of extending classes that wasn't fully covered was the idea of overriding a method in a class. You can override a method (function) from the base class by simply redefining the method in the child class. [...] There are times though, when you do not want a method to ever be overridden. There may even be cases where you do not want a class to be extended.

His example shows how to use this "final" keyword on a database class, protecting a method (getRecord) that could potentially break the application if changed. This would then give the developer trying to extend the class an error noting that that method cannot be overridden. One thing to note, if you're going to use "final" in your code, be sure you know what you're doing. More often than not, you probably just want something like "private" or "protected" (see this post for a bit more explanation).

On the Zumba Engineering blog today Chris Taylor has a new post about mocking in PHPUnit, specifically how to handle those pesky Singleton methods lurking around your codebase.

In many of our projects, utilities and vendor classes are implemented with a singleton pattern. [...] In this post, we'll cover a nice way to inject a PHPUnit mock object for use in testing methods that utilize singleton classes.

He starts by introducing mocking and how to use mock classes in PHPUnit with a simple "sayHello" example. Adding on another layer, he creates a "SomeclassMock" class, defining its own "expects" and "cleanup" methods. This class forces the Singleton method to act more like a regular non-static method and "resets" it after each use.

On PHPMaster.com today Alejandro Gervasio has a new tutorial posted about the Single Responsibility Principle - a guideline that states that each class should only have one "area of concern" and not try to do to much.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called "God class" is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

In his recent post Gonzalo Ayuso shows how to use Symfony to work with Windows services on the server.

Sometimes I need to stop/start remote Windows services with PHP. It's quite easy to do it with net commnand. This command is a tool for administration of Samba and remote CIFS servers. [...] Today we are going to create a PHP wrapper for [net rpc service].

He uses Behat to create a feature (test) file, the code behind the features and a service class that handles the actual work of interacting with the service (with methods to do things like stop, start and list running services). Examples of its use are also included.