Recipes for Decoupling
$39.00
Minimum price
$49.00
Suggested price

Recipes for Decoupling

About the Book

Software is never done. The world around your program changes faster than you want it to. Frameworks and libraries are abandoned and replaced with something better (or just something new), so you need to migrate. You can postpone this work for a bit, but eventually you'll have to catch up, or your project may end up hopelessly outdated. I'm sure you know one or two of those projects!

How can you make all of this easier for yourself and the future maintainers of the project? The keyword is "decoupling". You can change the design of your code to defend it against changes in any dependency your project relies on. Decoupling your code is a way to make it future-proof (without doing too much work that "you ain't gonna need").

About 10 years ago I started looking for ways to decouple my code, but at first I struggled to do it effectively. My code was decoupled in the wrong places, or in the wrong way. I got a better view on this topic after several intense experiences with some legacy projects, a big framework migration, and a complete project rewrite (that I'm sure could have been prevented). I've collected many recipes for decoupling along the way. This book gives you a practical overview of common situations that suffer from an often unintended high level of coupling in web applications. Of course, it also gives you step-by-step recipes to improve these situations. The examples in this book show you how to decouple from your web framework, templating engine, test framework, ORM, and so on.

Decoupling is one thing, but staying decoupled is something else entirely. That's why in this book we focus on how to solidify the decoupling rules with PHPStan, the automated static analysis tool for PHP. That way we don't have to rely on discipline and code reviews, but can let a tool point out possible coupling mistakes.

  • Share this book

  • Categories

    • Refactoring
    • PHP
    • Laravel
    • Symfony
    • Zend
    • Software Engineering
    • Automated Software Testing
    • Web Development
  • Feedback

    Email the Author(s)

About the Author

Matthias Noback
Matthias Noback

Matthias Noback has been building web applications since 2003. He is the author of Principles of Package Design and Object Design Style Guide and Advanced Web Application Architecture. He is a regular blogger, public speaker and trainer.

Matthias Noback

Episode 224

Bundles that include this book

$84.00
Suggested price
$55.00
Bundle Price
$98.00
Suggested price
$75.00
Bundle Price

Table of Contents

  • Introduction
    • Coupling, Why is it Bad?
    • Decoupling, How to Do it Efficiently?
    • Objection
    • What’s Special About This Book?
    • How to Stay Decoupled?
    • Who Should Read This Book?
    • Overview of the Contents
    • About the Author
    • Changelog
      • 10 May 2022
      • 17 May 2022
      • 26 May 2022
      • 31 May 2022
      • 7 June 2022
      • 15 June 2022
      • 29 June 2022
  • 1 Creating Custom Rules for PHPStan
    • Introduction
    • Analyzing Code with PHPStan
    • Catching Specific Node Types
    • Adding Automated Tests for a PHPStan Rule
    • Deriving Types from the Current Scope
    • Putting a Node in Context
    • Generalizing a Rule
    • Conclusion
  • 2 Web Frameworks
    • Introduction
    • Controllers
      • Show How the Response is Created
      • Only Use Constructor Injection for Dependencies
      • Make Every Step Explicit
      • Controllers Have No Parent Class
      • Every Action Has its Own Controller Class
      • Should We Use an HTTP Abstraction Library?
      • Rules for Decoupled Controllers
        • Forbidden Parent Classes
        • Allowing Only Parameters of a Certain Type
        • Enforcing Return Types
        • One Action Per Controller
    • Views
      • Pass All the Data That the Template Needs
      • Don’t Pass Objects That Don’t Belong in a Template
      • Rules for Decoupled Views
        • Don’t Use Certain Global Variables in a Template
        • Don’t Use Certain Functions in a Template
        • Don’t Pass Entities to a Template
    • Conclusion
  • 3 CLI Frameworks
    • Introduction
    • Input
      • Collect Input First
      • Jump to a Service
    • Output
      • Using an Observer for Showing Output
      • Generalizing the Solution with Event Dispatching
      • Turn the Command Class Itself Into an Event Subscriber
    • Controllers Should Call Framework-agnostic Services
    • Rules for Decoupling
      • Use InputInterface and OutputInterface Only in Command Classes
  • 4 Form Validation
    • Introduction
    • Form Validation
    • Protecting Data Inside the Model
    • Delegating Protection to Value Objects
    • Removing Duplicate Validation Logic
    • Defining an Explicit Shape for the Input Data
    • Rules for Decoupling
      • Don’t Pass a Single Array of Data to create()
    • Enforcing the Use of Closure-based Form Validation
    • Conclusion
  • 5 ORMs and the Database
    • Introduction
    • Repository: an Abstraction for Persistence
      • Trying an Alternative Implementation
    • Application-generated IDs
      • PHPStan Rule: Disallow Auto-incrementing Model IDs
    • Defining Our Own Object API
    • Custom Mapping Code
      • PHPStan Rule: Only Allow Calls to fromDatabaseRecord() from Repository Classes
    • No Magic Persistence of Related Objects
      • Using Aggregate Design Rules
      • Limiting Changes to One Entity
    • Introducing View Models
    • Provide Read Models When the Framework Needs Your Data
    • Use Domain Events Instead of Persistence Events
      • PHPStan Rule: Forbidden Parameter Types
    • Conclusion
  • 6 Test Frameworks
    • Introduction
    • Use Only the Most Basic Features of a Test Framework
    • Declare Test Dependencies Explicitly
      • PHPStan Rule: Don’t Allow PHPUnit Extensions
      • PHPStan Rule: Don’t Allow Class-level Set-up and Tear-down Functions
    • Assertions
    • Write Tests in Plain Code
    • Handwritten Test Doubles
      • PHPStan Rule: Don’t Generate Mocks
    • Conclusion
  • 7 Conclusion
  • 8 The End of the Book

The Leanpub 60-day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms

Do Well. Do Good.

Authors have earned$11,721,492writing, publishing and selling on Leanpub, earning 80% royalties while saving up to 25 million pounds of CO2 and up to 46,000 trees.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF, EPUB and/or MOBI files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub