In a new post to his blog, Leonid Mamchenkov has linked to a resource that aims to help developers refactor their code to use best practices and design patterns: Refactoring.Guru.

Refactoring.Guru is a great resource for learning about refactoring best practices and design patterns. A lot of the website’s content is also available as Dive into Design Patterns ebook.

Today I came across this GitHub repository, which makes this resource even better specifically for PHP developers. Yup, that’s right, the GitHub repository features all code examples written in PHP 7.3, making it super easy to jump into coding.

The repository includes a Composer configuration to pull in some analysis tools and includes examples of about twenty different design patterns in use.

Matthias Noback has kicked off a new series of posts on his site covering the use of the repository design pattern in different situations. In this first post he focuses on "test driving" classes for handing database queries and their results.

A test for a repository can't be a unit test; that wouldn't make sense. You'd leave a lot of assumptions untested. So, no mocking is allowed.

[...] But how do you test everything that is going on in a repository? Well, I found out a nice way of doing so, one that even allows you to use some kind of test-driven approach. In this article I'll cover one of the two main use cases for repositories: querying the database, and returning some objects for it. The other use case - storing and loading objects - will be discussed in another article.

He starts by getting everyone on the same page with a definition of a "query" and how it relates back to a repository class. He then walks through the process of how to test the class, first as a general "get all" query then with a check on the "active" state. Once the test goes green (successful), he adds more variations to both the tests and fixtures. There's not a lot of code examples in this post but it does show some good concepts to get you headed down the right path.

On the Sticher.io site a new tutorial has been posted introducing you to Laravel view models. This functionality allows you to remove view-only logic from other parts and isolate it for transformation.

View models are an abstraction to simplify controller and model code. View models are responsible for providing data to a view, which would otherwise come directly from the controller or the model. They allow a better separation of concerns, and provide more flexibility for the developer.

In essence, view models are simple classes that take some data, and transform it into something usable for the view.

The post starts with some of the basics behind the "view model" design pattern and jumps in to an example for a blog site. In it, the code pulls in the category listing that's needed to display the page, removing the need for it to be in the controller code. It also includes the addition of custom logic to the model and the refactoring that can help move the logic into it. The tutorial also includes a section covering some of the "niceties" that can be added including passing it directly to the view method, returning it as JSON and returning individual properties as JSON.

On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

• getting runtime instead of compile-time errors
• obfuscation of actual functionality
• increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

The StarTutorial site has posted the next article in their series introducing various design patterns and their use in PHP. In their latest tutorial they cover the Adapter pattern, a useful pattern for putting a unified interface in front of various functionality.

[The Adapter pattern] converts the interface of a class into another interface the clients expect. Adapter lets class work together that couldn’t otherwise because of incompatible interfaces.

In their example they talk about a traveller wanting to charge their devices but being frustrated by the different plugs around the world. This is where an adapter comes in handy, providing a standard method for interaction (the input plug) with a wide range of backend tools (the plugs all around the world). They use this example and built out "plug" and "socket" classes where the adapter class acts as a go-between for the plug and receptacle.

On his site Nikola Posa has a tutorial showing how to lazy load services with Zend Manager, a component of the Zend Framework. In this case, the "services" being loaded are in a dependency injection container.

Any more complex application includes a big dependency injection tree of services, some of which can have a more complicated creation logic. If the service is injected as a dependency, but not necessarily used at every execution, you may want to lazily initialize that service until it is really needed.

In those situations, you may be tempted to inject the entire Dependency Injection Container instead, and lazy-load that resource-hungry service. I find that to be an anti-pattern, and I explained my views in a blog post written some time ago.

He offers a better solution in the form of the proxy design pattern, making it possible to decouple the services from the dependency injection container. He provides examples of using this pattern along with the Zend Service Manager functionality to create the factories and the services configuration.

StarTutorial.com has posted a new tutorial in their series introducing commonly used design patterns. In their latest article they cover the State pattern.

[The State pattern] allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

In the example situation, a worker at a customer support company and his state when dealing with customers (happy/angry/moderate). They codify this in a SupportRep class with a "state" value to track his mood. They expand on this with some additional conditions for number of calls to change the state as time goes on. This requires several if/else statements to be added. They refactor this to reduce the clutter using the State pattern, passing off the logic to various "state" classes.

The StarTutorial site is back with the latest installment of their series covering common design patterns and their use in PHP. In this latest tutorial they cover the Composite pattern.

[The Composite pattern] allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

In their example, they tell a story about a Walmart worker that received comments from her manager about an issue with the number of cars per box. They define classes for each (Agnes, a Box and a Product), including basic functionality in each. They talk about possible ways to solve the "number of cars" problem in the code including conditional statements and other logic. This is pushed aside when a more sustainable solution is desired, one that makes use of common interfaces for multiple product types. The code examples for this new "composed" structure is included.

The StarTutorial.com site has posted the next in its series covering the definition and use of design patterns in PHP applications. In this latest tutorial they cover the Iterator pattern.

[The Iterator pattern] provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Much like the previous parts of the series, they set up a sample situation to show how the code could be created and how it can be refactored to use the design pattern. In this case, it's an example of women's versus men's products and the fact that they store their inventory differently behind the scenes. The initial code tries to manually merge these two lists by getting the names from each. This is then refactored to define the product types as iterators and pulling the information using a unified interface.

The StarTutorial.com site has continued their series covering common design patterns and their implementation in PHP. In their latest article they cover the Template Method pattern.

[This pattern] defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

In their example, they have two workers that have different schedules but with one difference. Instead of having implementations that differ widely between the two workers (represented by classes) they refactor the main class and allow for a doWork method to be defined in the child. This makes the parent class a sort of "template" for handling the processing with the child filling in the blanks.