Book Image

The Art of Modern PHP 8

By : Joseph Edmonds
5 (1)
Book Image

The Art of Modern PHP 8

5 (1)
By: Joseph Edmonds

Overview of this book

PHP has come a long way since its introduction. While the language has evolved with PHP 8, there are still a lot of websites running on a version of PHP that is no longer supported. If you are a PHP developer working with legacy PHP systems and want to discover the tenants of modern PHP, this is the book for you. The Art of Modern PHP 8 walks you through the latest PHP features and language concepts. The book helps you upgrade your knowledge of PHP programming and practices. Starting with object-oriented programming (OOP) in PHP and related language features, you'll work through modern programming techniques such as inheritance, understand how it contrasts with composition, and finally look at more advanced language features. You'll learn about the MVC pattern by developing your own MVC system and advance to understanding what a DI container does by building a toy DI container. The book gives you an overview of Composer and how to use it to create reusable PHP packages. You’ll also find techniques for deploying these packages to package libraries for other developers to explore. By the end of this PHP book, you'll have equipped yourself with modern server-side programming techniques using the latest versions of PHP.
Table of Contents (19 chapters)
Section 1 – PHP 8 OOP
Free Chapter
Chapter 1: Object-Oriented PHP
Section 2 – PHP Types
Chapter 5: Object Types, Interfaces, and Unions
Section 3 – Clean PHP 8 Patterns and Style
Section 4 – PHP 8 Composer Package Management (and PHP 8.1)
Section 5 – Bonus Section - PHP 8.1

The service locator anti-pattern

One aspect of using a container that I must caution you against is using it directly as a service locator. What I mean by this is that your code should almost exclusively have no idea or requirement to be loaded via the DI container. You should not be using the DI container directly in your code.

Your classes should simply define dependencies and then use those dependencies. There are very, very few circumstances where anything other than your front controller or outermost layer should know about the container.

Remember the rules of Fight Club? Well, it's the same here. Your objects don't know about the container, and no one talks about the container. We pretend that you spent hours carefully hand wiring and instantiating all the objects required for your app to serve a particular request.

If you do write code that uses the container directly to retrieve services, then you have built a huge amount of coupling into your container and...