On the Master Zend Framework site Matthew Setter has posted a tutorial introducing you to delegator factories and what they're useful for in Zend Framework-based applications.

Ever wanted to dynamically expand the functionality of an object which you retrieve from your dependency injection container, based on different needs, yet without creating messy, hard to maintain configurations? If so, then you're going to want to know about a powerful technique called Delegator Factories.

He starts with a brief definition of what the factories are and the basics of what they allow you to do (briefly stated, they decorate DI services from the container). He then gets into a practical example, showing the update of a script from v2 to v3 of Zend Expressive, to wrap route definitions in a delegator to handle the difference. Complete code is provided as well showing the initial version of the routing code and the application of the delegator.

On the Laravel News site, there's an article posted covering the use of factory callbacks and closures in guards in Laravel. This feature was snuck into a recent release and allows you to provide a bit more dynamic functionality to your models and guards.

Two undocumented (before today anyhow) features were recently added to the Laravel 5.6 documentation, and they are both fantastic!

The post details each of the two new additions starting with the factory callbacks allowing you to perform additional tasks when a model is made or created (code examples included). The guard changes allowing closures and the Auth::viaRequest method to define new guard drivers.

The Laravel News site has posted a tutorial that takes you deeper with factories when using the framework looking at the factory states.

I suspect that if you are familiar with Laravel that you might use factories and possibly even factory states in your application development. The documentation shows you the mechanics of using factories to seed and create test data, but there are a couple of guiding thoughts to using factories with your models effectively that I’d like to consider.

He starts with two options he sees for using factory states: making them with static values or using them to make simple models instead. He goes through these two options, introducing some of the basic concepts of each, how it would work and the code to make it happen. He also covers a few other approaches including the use of a trait to include the factory functionality directly in a class. He finishes the post with a few links to more information in the Laravel manual and other outside resources/tools.

The Pehapkari.cz blog has posted the latest article in their "Domain-Driven Design" series of posts covering the focus on the "domain" when developing an application rather than just features. In this latest tutorial, they cover services and factories to help with the encapsulation of functionality...and why they shouldn't be used.

This article is a reaction to readers’ confusion about services. We'll cover a domain service and domain factory in this article and when to use them and when not to.

Domain-driven design is about the domain. Domain services and domain factories do not exist in the domain. In general, we shouldn't use them. They are artificial constructions and this causes a lot of problems with code understanding, maintainability and also a divergence between the domain, the model, and the code.

The article continues the use of the e-commerce example when talking about the ideas of services and factories in the domain. It provides some basic examples (flow diagrams included) and the reasoning why they should not be used and what they could be replaced with.

The StarTutorial.com site has posted the next in their "Understanding Design Patterns" series of tutorials today. In this latest post they cover the Factory design pattern.

[The Factory design pattern provides] an interface for creating families of related or dependent objects without specifying their concrete classes.

They use the same fictional business as in the previous articles to put the pattern in a more "real world" situation. The goal is to create several "toy factories" that can build "toy" objects based on certain requirements: either cars or helicopters. The post starts with the creation of an abstract factory class and shows the concrete implementations of one for each type of toy. These concrete classes include basic properties about the toy and functionality to build out the basics (ex: a car has four wheels, a helicopter has rotors).

On the StarTutorial.com site, they've posted the latest in their article series covering design patterns and their implementation in PHP. In this latest tutorial they cover the simple factory pattern. To help illustrate the point of the pattern they use an example of a toy company with an ever-expanding line of toys.

Dragon Inc. is one of the top toy manufacturers in China. In fact, they're a pioneer in toy manufacturing. They started production at a time when few toys were being produced commercially. Hence, they dominated the market and became the leader in the toy production industry.

The initial version of their produceToy method only had to worry about toy cars and helicopters. As their line expanded, it needed to be updated for "jumping frogs" too. Adding each new toy to the single function would be difficult to maintain but the simple factory pattern came to the rescue. It allowed for the abstraction of the toy object creation out to other handling and other objects, breaking the functionality up in accordance with the Single Responsibility Principle.

In a post to his site Nikola Poša looks at a method that can be used to provide a slightly different object from a dependency injection container based on other criteria: making use of a factory as a service.

Dependency Injection Containers are a great invention - when used the right way, they allow us to keep our factories and assembly logic of services outside the core business logic of our application.

By default, a service created is shared, meaning that exactly the same instance will be returned whenever service is retrieved from a container. This is a desired behaviour in most of the cases. [...] Yet certain use cases may require services to be created conditionally during runtime, such as for example based on the value of a parameter resolved from the current request.

He first covers some of the anti-patterns that could be used to resolve this issue: a setter method on the returned object, using a service manager or creating a static factory instead. He offers a solution to the problem that makes use of a factory inside of the DI container. This factory then uses configuration values from the container to set up the object and return it.

Sergey Zhuk has written up a post to his site that wonders if the factory method violates the open/closed principle, a part of the SOLID set of principles for software development.

Consider an application that provides some statistics reports. Reports are present in different formats: JSON for API, HTML for viewing in a browser and pdf for printing on the paper. It has StatisticsController that receives a required format from the request and returns a formatted report. The logic for choosing a formatting strategy is hidden behind the factory.

He works through a code example of using the factory pattern to create this functionality, generating the fomatter from behind the factory. He then talks about adding a new formatter for CSVs and the update to the factory that would come with it. It's this last change he's wondering about as the Open/Closed principle states that objects should be open for extension but not modification. While the answer is technically "yes" he explains that the purpose of the factory is to abstract the logic away so you only have to deal with one type of thing rather than making it yourself every time.

According to Open-Closed Principle the “correct” solution would be to create a new factory with the same interface. That said, adherence to this principle should always be weighed against other design principles like KISS and YAGNI.

Rob Allen has a new post to his site showing how you can customize the Whoops output in a Zend Expressive application. Whoops is a package that provides more well-structured and more attractive error output when an issue comes up.

I find the Whoops error handler page in Expressive quite hard to read and particularly dislike that the error message displayed in the top left is hidden if it's more than a few words long.

To fix this, I discovered that you can provide a custom CSS file to the PrettyPrintHandler and then override to your heart's content! One way to do this is to add a delegator factory to add the additional functionality, so let's do that.

He then includes the configuration changes you'll need to make in the Expressive setup to have it recognize the factory and be able to use it as a dependency. He then includes the code to create the factory itself, adding a path to the local CSS files and pushing the custom whoops.css file into the page handler. Example CSS is included showing an update to the display of the main message, removing the need for a mouseover to view it.

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.