Matt Stauffer continues his series covering features in the 5.4 version of the Laravel framework with this look at real-time facades, a feature that allows you to use facades on classes without having to pre-define them as before.

Laravel 5.4 introduced a new feature called “real-time facades”, which provide the convenience of facades, defined real-time instead of in classes. Taylor tweeted about it, but I wanted to explain what they are and how they work.

[...] If you’re not familiar with facades in Laravel, they’re shortcut classes that provide static access to non-static methods on service classes bound to Laravel’s container. [...] Real-time facades let you create your own facades on the fly. Instead of having to create a facade class like the Session facade class I referenced above, you can use a class as its own facade by adding Facades to the beginning of its own namespace.

He includes code showing how facades are used and what kind of functionality they offer. He then covers the switch to the real-time version, switching up the namespace to tell the framework to perform the new logic. He ends the post with examples of this functionality in use inside of a view, class or any other library in your application.

On his Medium.com blog Laravel project lead Taylor Otwell shares some of his thoughts on expressive code and real-time facades and how they make things simpler, event for testing/mocking.

Recently, I worked on some code that surfaced my most common use-case for Laravel 5.4’s “real-time” facades. If you’re not familiar with this feature, it allows you to use any of your application’s classes as a Laravel “facade” on-demand by prefixingFacades to the namespace when importing the class. This is not a feature that is littered throughout my code, but I find it occasionally provides a clean, testable approach to writing expressive object APIs.

To illustrate he uses the code from the Laravel Forge service talking about service providers (like DigitalOcean, Linode, etc) and "service" classes to contain API methods. He then shifts over to the controller to see how he'd like to access it, making a generic Provider class with a make method to create the instance. This has an issue, however, with testing making it very difficult. Instead he shifts over to the real-time facades and a factory where the test can more easily manually mock the method into a stub provider (example included).

On his Unnikked site Nicola Malizia has written up a post sharing some insight into how Laravel's automatic facades work, a feature that was introduced in Laravel v5.4.

Another cool feature shipped with the release of Laravel 5.4 is the ability to use Facades on the fly. Automatic Facades with the official documentation is quite informative. So I assume you are familiar with them.

He then starts in on the creation of custom facades: defining the functionality (a class), creating the facade and updating the app config to load it in. He then covers what's happening behind the scenes when the "Facades" namespace is loaded and the facade is called (lots of code snippets included here).

My suggestion is to start using automatic facades whenever is possible, their impact is negligible. To see when to use facades in general a good read is available in the official documentation.

David Lundgren has a post to his site talking about the allure of static proxies in your development and some of his own experiences using them in his own code (and in using Laravel).

Several weeks ago I started playing with Laravel. Primarily because several colleagues are using it, and have suggested that I take a look at it. During my time reviewing how to build a view template I came across references to Html, Form, View and other static calls. Initially I was not impressed due to the use of so many static calls. I have come to an understanding about how static calls in certain circumstances can actually enhance code readability.

He talks about how static calls have been considered an anti-pattern for a long time due to difficulty testing and tight coupling issues. That being said, he did start to see the value in using them in certain situations, how his use relates to the proxy design pattern and some of his own conclusions about using static calls.

The QaFoo blog has a post today about outside-in testing, two design patterns - Adapter and Facade - and how they relate.

As part of our workshops on Test-Driven Development we explain to our customers how testing from the outside-in can help find the right test-mix.

The technique puts a focus on test-driven-development, but instead of the traditional approach starts at the acceptance test level. The first test for a feature is an acceptance test and only then the feature is implemented from the outside classes first. [...] Outside-In testing leads to interfaces that are written from what is useful for the client object using them, in contrast to objects that are composed of collaborators that already exist. Because at some point we have to interact with objects that exist already, we will need three techniques to link those newly created interfaces/roles to existing code in our project

These three techniques are:

• using the adapter pattern to interface with third party code
• the facade pattern to "layer" your own code
• continuous refactoring of interfaces/implementations

In this post they focus mostly on the adapter pattern. They show how to use it in interfacing with remote systems in a Symfony application (for example) based on a remote XML file. They also include the test to verify it's functioning correctly and the PHP code to make the mocks and interfaces you'll need for the test.

The TutsPlus.com site has posted a tutorial for those either new to the Laravel framework or wanting to get started a bit easier. In this new post they talk about the "facades" the framework makes wide use of - what they are and how they work.

The facade is very similar to the adapter and decorator patterns. The adapter acts like a bridge between two interfaces which are not compatible, while the decorator is more complex and used for dynamically changing the way objects behave.

[...] Sweet syntax, which Laravel uses, makes writing code cleaner and easier to understand. Laravel facades are actually the syntactic sugar for service location.

He uses the Cache facade in his introduction, showing where the various parts of it are defined and how it hooks in to the framework's functionality. With the basics out of the way he then shows how to create a custom facade instance: a simple check to see if the file name provided is a PDF or not.

The SitePoint PHP blog has a new tutorial posted showing you how Laravel Facades work and how they ("Facades") can be used in other framework types.

The Facade pattern is a software design pattern which is often used in object oriented programming. A facade is, in fact, a class wrapping a complex library to provide a simpler and more readable interface to it. The Facade pattern can also be used to provide a unified and well-designed API to a group of complex and poorly designed APIs. The Laravel framework has a feature similar to this pattern, also termed Facades. In this tutorial we will learn how to bring Laravel’s "Facades" to other frameworks.

He starts off by looking at how the Laravel framework has implemented facades through out the entire framework. He includes examples of using these facades (like the App to make a new object instance) and how the base Facade class is structured to make it work. He covers some of the basic features of the classes that extend this base and how they're aliased in the Laravel code/configuration. He then gets into using this same sort of "facade" approach to other frameworks, specifically in an app based on the Silex microframework. He lists some of the requirements and shows how to pull in the base Facade class to extend. He also integrates the aliasing code and configuration to make it simpler to use the short names rather than full namespaced versions of the classes.

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.

The NetTuts.com site has a new tutorial posted today sharing more information about the authentication facade in Laravel 5 and how to use it to implement simple, custom authentication handling.

Authentication is a part of almost all the web applications you work with. It's really boring to keep repeating all the boilerplate code in every project. Well, the good news is Laravel 5 rids you of this boredom by providing a ready-to-use authentication facade. All you need to do is configure and customize the authentication service provider to your project's needs. In this quick tip, I am going to show you exactly how to do that.

It's a seven step process to get things up and running (it sounds like a lot but all the code is provided):

• Setting Up the Environment
• Setting Up the Migrations
• Configuring the Registrar Service
• Updating the User Model
• Updating the View
• Securing Your Routes
• Modifying the Default Authentication Routes

Each step includes the code needed and a brief summary of what's happening and how it effects the overall authentication setup. He also ends the post with a brief mention of the "password reset" email functionality and where the content for that email is located.

NetTuts.com has continued their series covering common design patterns and their implementation in some example PHP scripts today. In their latest post they focus on the Facade pattern, a member of the "structural" family of patterns.

When it comes to design patterns, you may have questions: Why should we use design patterns in programming? Our code can work just fine without it. [...] Code that employs design patterns is easy to understand, easy to maintain, and easy to extend.[...] In this tutorial, we are going to cover the facade design pattern. It falls under the category of structural patterns because it deals with how your code should be structured to make it easily intelligible and keep it well maintained in the long term.

They start with a UML layout of a typical Facade and include a typical problem/solution where it could be used. They get into a code example that creates a simple checkout process. In this process, they use the Facade pattern to create a more maintainable, extensible ordering workflow.