Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Mark Baker:
In Search of an Anonymous Class Factory
May 03, 2016 @ 10:49:25

In a new post to his site Mark Baker take a look at anonymous classes, a new feature in PHP 7, and a challenge he took on to figure out how to apply traits to them at runtime.

One of the more interesting new features introduced to PHP with the arrival of version 7 is Anonymous Classes. [...] Then back in January (as I was waiting for my flight to the continent for PHPBenelux) I was intrigued by a request to find a way of dynamically applying Traits to a class at run-time. With time on my hands as I was sitting in the airport, I considered the problem.

His first idea was to build an anonymous class, extending the requested class that would come along with the traits/properties/functionality of the original class. He includes some of the code he tried to implement this solution and ultimately figured out that a factory would be a good approach to creating the structure. After doing some research he found a way to create the factory using some eval magic. However, this wasn't "the end of the story" as he found out some other interesting things about anonymous classes (such as the fact that they're linked to only one instance of a class, making them less reusable).

tagged: anonymous class php7 factory eval example

Link: https://markbakeruk.net/2016/05/03/in-search-of-an-anonymous-class-factory/

Rob Allen:
DI Factories for Slim controllers
Apr 28, 2016 @ 10:38:10

In a recent post to his site Rob Allen shows you how to create dependency injection factories for Slim (v3) controllers.

When using classes for route actions in Slim 3, I recommend using a single class for each route. However you can use a single class for multiple routes. To register a class method to a route you pass a string as the route callable where the class name is separate from method by a colon. Slim will retrieve MyController from the DI container and then call the listAction method using the usual signature. f you don't specify a method, then Slim will see if it treat the class as a callable, so you can implement __invoke() and then register the route.

He shows how to create a factory method as a part of the Slim container for a constructor and inject the correct dependencies. He shows how to register these dependencies as other factory methods inside the DI container and how to pull them back out for injection. He prefers this method as it reduces "hidden dependency" issues and makes the controllers themselves easier to test.

tagged: slim3 slimframework dependency injection container tutorial factory

Link: https://akrabat.com/di-factories-for-slim-controllers/

Marc Morera:
You Probably Need Bundle Dependencies
Feb 10, 2016 @ 09:04:18

In this post to his site Marc Morera responds to some comments from another post about bundles dependencies in Symfony-based applications.

This post tries to answer the Magnus Nordlander’s blog post, and to explain why the Symfony Bundle Dependencies is not just a personal project to fulfill my bundles dependencies, but a practice we should implement in all our Symfony bundles as well.

Believe me, I had a big post to explain why people really need this bundle, but I think that you don’t need these words, but a simple and real example.

He points out a more "real world" example of why this kind of dependency system can be useful in Symfony development. He points out a common service (security.encoder_factory) that's used widely across many bundles, but also defined as a dependency in each. If the bundle dependency structure/tool was in wide use, this dependency would be define elsewhere and not as a part of the bundle itself.

tagged: bundle dependencies symfony security factory example

Link: http://mmoreram.com/blog/2016/02/09/you-probably-need-bundle-dependencies/

SitePoint PHP Blog:
Flyweight Design Pattern and Immutability: A Perfect Match
Oct 22, 2015 @ 11:56:32

The SitePoint PHP blog has a tutorial they've posted (from author Andrew Carter) looking at the Flyweight design pattern and immutability, how they're a "perfect match". The flyweight pattern makes it possible to reuse objects after they've been created with one requirement: they must be immutable.

The fundamental principle behind the flyweight pattern is that memory can be saved by remembering objects after they have been created. Then, if the same objects need to be used again, resources do not have to be wasted recreating them. [...] You can think of the flyweight pattern as a modification to a conventional object factory.

One important feature of flyweight objects is that they are immutable. This means that they cannot be changed once they have been constructed. This is because our factory can only guarantee that it has remembered the correct object if it can also guarantee that the object it originally created has not been modified.

The post includes code examples of how to implement the pattern with a simple File object that fetches data from a file when created. He then creates the factory class, with a getFile method that takes in the path and creates the immutable File object from it. It's then stored in an internal array for potential reuse later. He also talks about how the pattern could be useful for handling enumeration objects and how you can use it to build out "type" objects.

tagged: flyweight designpattern immutable object factory tutorial type enumeration

Link: http://www.sitepoint.com/flyweight-design-pattern-immutability-perfect-match/

Laravel News:
Learn to use Model Factories in Laravel 5.1
Oct 08, 2015 @ 10:46:21

On the Laravel News site there's a tutorial helping you learn to use Model factories in your Laravel 5.1+ application. These factories make it easy to create instances of "fake" models that can be interacted with as if they were the real thing.

These have several use cases with the two biggest being–testing and database seeding. Let’s take a deeper look at this feature by building out the beginning of a little fictional app.

They provide a situation where these factories can solve a potential problem: making an application easier to test because of the (potentially) high volume of customers. He walks you through the creation of a new application and building out the models and matching migrations. Next up is the generation of the database seed values and, finally, the creation of the fake models and the code needed to connect it all together. The post ends with a look at using these factories to generate models in tests, creating them with simple data and some of the other features they offer.

tagged: model factory laravel fake tutorial testing introduction

Link: https://laravel-news.com/2015/10/learn-to-use-model-factories-in-laravel-5-1/

Rob Allen:
Custom OAuth2 authentication in Apiiglity
Jul 21, 2015 @ 09:05:49

In an article posted to his site Rob Allen shows you how to hook in the OAuth2 authentication for an Apigility-based application with a pre-existing database table structure that may not match the defaults Apigility is looking for.

I have a client that's writing an Apigility API that needs to talk to a database that's already in place. This also includes the users table that is to be used with Apigility's OAuth2 authentication. Getting Apigility's OAuth2 integration to talk to a specific table name is quite easy. [...] However, if you want to use different column names, that's a bit trickier as they are hardcoded in the OAuth2StoragePdo class. To get Apigility's OAuth2 components to look at the correct columns, you create your own OAuth2 Adapter. I chose to extend ZFOAuth2AdapterPdoAdapter which extends OAuth2StoragePdo and go from there.

He includes the code for this extension of the PdoAdapter (a "OAuth2Adapter" class) in the post showing the definitions of the get user, set user and check password methods the OAuth2 flow needs to match users to OAuth sessions. He also includes the code for the "OAuth2AdapterFactory" class that's used to pull the custom PDO adapter class into Apigility and, along with some configuration changes, make it available for use. Then it's just a simple matter of changing the authentication type in the Apigility UI.

tagged: apigility oauth2 authentication custom factory pdo adapter oauth tutorial

Link: http://akrabat.com/custom-oauth2-authentication-in-apiiglity/

Paul Jones:
A Factory Should Create, Not Retain
Jul 08, 2015 @ 08:45:31

Paul Jones has posted his thoughts about factory behavior in PHP applications (well, really any kind of application as it's a pan-language concept). He suggests that factories should only create the objects requested and not persist them.

In a recent Reddit conversation, some of us went off on a tangent about factories. I maintained then, and do now, that a “factory” always-and-only returns a new instance. If you have a “factory” that returns anything other than a new instance, it’s not a factory alone. In the case of factory methods, it is a factory + accessor; in the case of factory objects, it is a factory + registry. A “factory” (whether a factory method or factory object) is one way to separate object creation from object use.

He gives an example of a case where an object needs to be created for a "doSomething" method. His first example shows the creation of the "Item" inline, mixing the creation and use of the object into the same place. He replaces this with a "factory" class/method that only returns the new "Item" requested. He points out that a factory method that retains the object (like as a class property) has the same problem as the first example - retention. Instead he suggests an intermediate "collaborator" that splits out the creation and retention once again.

tagged: factory retain create object method collaborator example

Link: http://paul-m-jones.com/archives/6161

Stephan Hochdörfer:
Simple Logging Facade for PSR-3 loggers
Jun 17, 2015 @ 09:56:45

In his latest post Stephan Hochdörfer shares a library he's created to hopefully make it easier for developers to integrate PSR-3 compatible logging libraries into their code, a "logging facade" based on an idea from the Java world.

Lately I have seen more and more libraries picking up PSR-3 when it comes to logging. What a lot of libaries do wrong is that they depend on a concrete implementation of PSR-3, e.g. Mongolog instead of relying on the PSR-3 interface. From what I have seen this is because loggers get instantiated directly within the class. This is not a bad thing but it couples your code to a concrete implementation of PSR-3 which in turn means that there`s no interoperability.

The Java community solved the problem by creating a Simple Logging Facade library (SLF4) which I "ported" to PHP last week.

The library makes provides a simple static interface to setting the PSR-3 logger of your choice and fetching it from anywhere in your application. He includes an example of what the code would look like for a basic Monolog instance. He ends the post talking about this method for getting/setting the logger instance and how it compares to using other options like a dependency injection container or even just a manual call to a setter.

tagged: logger facade factory psr3 monolog example library

Link: https://blog.bitexpert.de/blog/simple-logging-facade-for-psr-3-loggers/

Marc Morera:
Defeating Expression Language
May 18, 2015 @ 08:38:27

Marc Morera has a new post to his site wanting to help you defeat Symfony's expression language and perform the same functionality, just more on the code side (another option).

How beautiful Expression Language definitions are, right? I mean, inserting that complex expressions in a Dependency Injection configuration file is so nice and fast if you need to inject the result of a method in a service (one of the multiple examples we can see). [...] This is not a bad idea, really, but because we are engineers and we should have as much information as possible in order to be able to choose between the best option, always, I will show you another way of defining this piece of code.

He shows how to write some code using the Factory design pattern structure to reproduce a bit more complex piece of expression language. He shows the setup of the services.yml file to define the "managers" and classes/services to be injected. He also notes that this removes the need for the "symfony/expression-language" dependency and makes things more portable in the future.

tagged: expression language symfony alternative factory dependencyinjection services configuration

Link: http://mmoreram.com/blog/2015/05/18/defeating-expression-language/

NetTuts.com:
Design Patterns: The Simple Factory Pattern
Jan 27, 2015 @ 11:53:20

NetTuts.com has posted the next part of their series focusing on design patterns (and more specifically implementing them in PHP). In this latest post they look at a simple version of the Factory design pattern.

When you think of a factory, what comes to mind? For me, it's a place where things are created - that is, it's a centralized placed where things are produced. Later, the delivery of said products are done by the factory based on an order. Let's say that you're requesting a car. A factory will create one based on the specifications of the work order and will then deliver it once it's complete. Just as their real world counterparts, a software factory (that is, software that implements the factory design pattern), is an object that is responsible for creating and delivering other objects based on incoming parameters.

They mention the three different versions of the factory pattern but focus in on the simplest one (hence the "simple" in the title). They continue on with the car example, showing how to use a simple factory (a "carFactory") to build an instance of the "Car" class based on different classes of car types. The object is constructed when a "build" method is called with the type.

tagged: designpattern simple factory car type example tutorial introduction

Link: http://code.tutsplus.com/tutorials/design-patterns-the-simple-factory-pattern--cms-22345