Robert Basic has a quick post to his site where he shows how to use partial mocks in Mockery, a useful tool for unit testing in PHP applications.

In dealing with legacy code I often come across some class that extends a big base abstract class, and the methods of that class call methods on that big base abstract class that do an awful lot of things. I myself have written such classes and methods in the past. Live and learn.

One of the biggest problems with this kind of code is that it is pretty hard to test. The methods from the base class can return other objects, have side effects, do HTTP calls…

He gives an example of a model that includes a method returning a database connection. In the child class of this the method that he's wanting to test includes a call to this method, making it difficult to test in isolation. He then shows how to make a partial mock of the child class that, be definition, returns a mocked PDO instance instead of the real PDO instance. All other methods will be passed through to the real class.

Alejandro Celaya has a new post to his site showing the Zend Framework users out there how you can reuse factories in Zend/ServiceManager. Factories are heavily utilized by the component to create the objects the service returns. Factories tend to be single-use, however, but Alejandro has shown a way around that.

I like zend-servicemanager because it is explicit, and you are always in control of what's done, without loosing flexibility in the process. Since this container expects you to define factories for every service, you usually end up writing, testing and maintaining a lot of factories that doesn't add value to the application.

That's why it is so important to properly reuse factories when possible, not only because you will have to maintain less classes, but because the ServiceManager will instantiate less objects at runtime when it can reuse a factory.

He then talks about ways you can set up shared factories in your application including the use of an abstract factory class or a concrete factory to return other dependencies required. He also shows how to use the ConfigAbstractFactory that allows for the injection of dependencies based on a configuration (similar to the "wiring" in other dependency injection containers). Finally he shows the use of the ReflectionBasedAbstractFactory that handles the injection in about the same way but instead of basing it on a configuration it uses PHP's own reflection to try to determine the class and autoload it into the current system.

Gary Hockin has a post to his site today introducing you to the new ConfigAbstractFactory class to work with ZendServiceManager in Zend Framework applications. The library helps make the creation of configuration service factories easier than having to write them in code.

I wanted to introduce the new ConfigAbstractFactory that has been written for ZendServiceManager 3 and got merged to develop today and will be included in the next 3.2.0 release of the ServiceManager.

[...] Laravel has shown us that developer usability is a real thing and that by making things easier for your target audience you gain traction and Good Things Happen. This is why in response to an issue on the Service Manager repository, I’ve written the catchily named Config Abstract Factory. Essentially, it allows you to create service factories from configuration rather than having to write all the code.

He talks about being a fan of the "configuration over magic" approach the Zend Framework has and how, with this new new library, it makes it even easier to directly link configuration files and the objects created based on their contents. He gives a simple example of a UserServiceFactory, first showing the "old" way of handling it then how to shift over to the new abstract handler just defining the same setup in the module configuration.

On the QaFoo blog they've posted an article that shares some of their thoughts on "when to abstract" in your code - essentially finding that point where abstracting out functionality makes sense.

One of the most difficult challenges in a developers life is finding the "right" abstraction, or at least the best one given the current circumstances. The core problem is that abstraction is a bet on the future development of the software and we know that future is volatile. The circumstances will change, so will the view on the best abstraction change.

But there is another dimension which influences this decision: What kind of software are you developing?

They start off by defining three different types of projects (internal, library and adaptable) and move into how this type changes when/how you abstract things in your code. They give a brief summary for each type and when it usually makes sense, including steps to take (concrete first, then abstract).

In a new tutorial from the SitePoint PHP blog editor Bruno Skvorc shows you how to "break free" from using the Guzzle HTTP client (which has become, by far, the most popular) and make it simpler to go with another option. He highlights the HTTPlug library that makes it easy to do just that.

In a previous series, we built a PHP client for Diffbot. The client works well and is in relatively widespread use – we even tested it on a live app to make sure it’s up to par – but it depends heavily on Guzzle 5.

There are two problems with this: Guzzle 6 is out, and supports PSR 7. [...] Someone implementing our client in their app might already have a preferred HTTP client in use, and would like to use theirs rather than Guzzle. [...] Coincidentally, there is a new project allowing us to do just that: HTTPlug.

He walks you through the installation of the library via Composer and covers what all kinds of functionality it contains. HTTPlug provides an "entry point" and unified interface for the HTTP client of your choosing, complete with interface packages to wrap the most common functionality. He shows how to refactor his Diffbot code to use the package, replacing the previous Guzzle dependency using the virtual package definition HTTPlug provides. He also updates some of the tests to use the HTTPlug package types rather than relying on Guzzle's object return types.

Paul Jones has an interesting post to his site that makes the link between software versioning and public interfaces your code provides. He points out that, despite semantic versioning helping to define how to version your code, there's still some ambiguity about it and backwards compatibility.

Adherence to Semantic Versioning is just The Right Thing To Do, but it turns out you have to be extra-careful when modifying public interfaces to maintain backwards compatibility. This is obvious on reflection, but I never thought about it beforehand. Thanks to Hari KT for pointing it out. Why do you have to be extra-careful with interfaces and SemVer? [...] If we remove a public method, that’s clearly a BC break. If we add a non-optional parameter to an existing public method, that’s also clearly a BC break. [...] However, if we add a new public method to the concrete class, that is not a BC break. Likewise, changing the signature of an existing method to add an optional parameter is not a BC break either. [...] But what happens with an interface?

He suggests that changing current functionality (such as adding a non-optional parameter) is a backwards compatibility break but in an interface so is adding a new method. By adding a method you "break" the implementation someone already has, causing plenty of trouble for the users. He wonders about the right approach for making these updates, if it's creating a new interface or just extending the current one and having users migrate. He also includes a few update notes about abstract classes and how Symfony handles BC breaks too.

In his most recent post Marc Morera says bye bye to Symfony and "hello to PHP". Confused? His point is that using the Symfony components as a whole in the framework isn't the only option anymore. You can use them just as effectively as pieces of a larger PHP project, puling them in as needed.

The reason of this post is just to tell you, with a simple example, how to say Bye Bye, Symfony! and say Hi PHP!. This really means uncouple from Symfony Components and still use them as the default implementation, while we can securely remove, from the composer require block, our Symfony dependencies.

He starts off with a simple example showing how to use Symfony's "UrlGeneratorInterface" to create a URL output class that can be injected to use in the route handling of the application. He then moves on to a more real-life example (a metaphor) using a USB connection and the adapters/cables that could be involved to connect various devices. He then shifts back over to the world of code and describes a specification interface that can be used with the URL generation and remove the Symfony dependency from it. On top of this he builds an adapter object that brings the Symfony component back into the picture and abstracts it out a level to make for more flexibility and testability in the long run.

We win maximum implementation flexibility and minimum coupling. Would be wise to say that a PHP project should tend to this thought, but once again, it depends on many factors. [...] Using ports and adapters is really a great tool for those who want to uncouple from implementations and a great pattern if you develop open source. Open source should satisfy as people as possible, so remember, specify and then implement.

On the Master Zend Framework site today Matthew Setter has a new post covering the configuring of the service manager using abstract factories.

One of the best features about Zend Framework 2 is undoubtedly the ServiceManager; because it makes it almost painless to configure and retrieve services in a consistent and predictable manner, anywhere in your application, at any time. [...] But the catch is, there’s quite a bit to learn if you want to use it properly. As well as that, there’s quite a number of ways to use it.

He walks you through some of the pros and cons of the various ways to work with the ServiceManager and where the factories fit in. He takes a bit of time to introduce the concepts behind abstract factories and how to define them in a Zend Framework v2 application. He finishes out the post with a more practical, working example using the interfaces provided to get a "MyUserTable" service.

The SitePoint PHP blog has a new tutorial today from Lukas White showing you how to work with abstract file systems that aren't local. In this case, the file system is virtual and living on a remote system.

Reading and writing files is an integral aspect of any programming language, but the underlying implementation can vary enormously. For example, the finer details of writing data to the local filesystem compared to uploading over FTP is very different – yet conceptually, it’s very similar. In addition to old warhorses like FTP, online storage is increasingly ubiquitous and inexpensive – with scores of services available such as Dropbox, Amazon’s S3 and Rackspace’s Cloud Files – but these all use subtly different methods for reading and writing. That’s where flysystem comes in.

He shows how to install the flysystem library (via Composer) and a few examples showing how to make connections to:

• an Amazon S3 instance
• a Dropbox account
• SFTP
• even Memcache

Examples of both reading and writing to this virtual system are also included as well as a few other features like handling visibility, listing files/directories and mounting the remote filesystem locally.

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.