Solid on Brian Faust

Dependency Inversion Lets Policy Own the Boundary

Tue, 01 Jun 2021 00:00:00 +0000

This class uses constructor injection and still points in the wrong direction:

final readonly class QuoteShipment
{
 public function __construct(private GuzzleHttp\Client $http) {}

 public function handle(Shipment $shipment): Money
 {
 $response = $this->http->post('/carrier/rates', [
 'json' => CarrierPayload::fromShipment($shipment),
 ]);

 return Money::EUR(
 json_decode($response->getBody(), true)['price_cents'],
 );
 }
}

The dependency is visible and testable, but the application use case knows an HTTP client, carrier endpoint, payload, response shape, and currency assumption. Replacing new Client() with an injected client improved assembly; it did not protect policy from the detail.

Interfaces Belong to Their Clients

Sat, 01 May 2021 00:00:00 +0000

A carrier integration often begins with one generous interface:

interface Carrier
{
 public function quote(Shipment $shipment): ShippingQuote;
 public function buyLabel(Shipment $shipment): Label;
 public function cancelLabel(LabelId $labelId): void;
 public function track(TrackingNumber $number): TrackingStatus;
 public function bookPickup(PickupRequest $request): Pickup;
 public function closeManifest(LocalDate $date): Manifest;
}

The checkout page needs only quote(). A tracking job needs only track(). One carrier may not support pickups; another may not use manifests. The broad interface makes every consumer and implementation participate in capabilities they do not share.

The Interface Segregation Principle asks for client-specific contracts. It does not demand one method per interface. Split where clients, implementations, or change reasons diverge.

Substitution Is a Behavioral Contract

Thu, 01 Apr 2021 00:00:00 +0000

Both of these classes implement the same interface:

interface InvoiceArchive
{
 public function store(InvoiceId $id, PdfDocument $document): Location;
 public function read(Location $location): PdfDocument;
}

final class NullInvoiceArchive implements InvoiceArchive
{
 public function store(InvoiceId $id, PdfDocument $document): Location
 {
 return Location::from("memory://{$id->value}.pdf");
 }

 public function read(Location $location): PdfDocument
 {
 throw new RuntimeException('Nothing was stored.');
 }
}

PHP accepts the implementation. A client that stores a document and later reads the returned location does not. The method signatures match while the behavioral contract is broken.

The Liskov Substitution Principle is about that gap. Code written against a supertype must continue to work when it receives any subtype. Interfaces, inheritance, fakes, decorators, and adapters all create subtype promises; the principle is not limited to class hierarchies.

Open–Closed Protects Stable Policy from Repeated Variation

Mon, 01 Mar 2021 00:00:00 +0000

The third shipping carrier usually exposes the design more clearly than the first.

With one carrier, a conditional is honest. With three, adding a carrier may require editing quote calculation, label purchase, tracking links, validation, service-provider bindings, and tests. The same variation keeps reopening code that was already working.

The Open–Closed Principle addresses that pattern: establish a stable policy that is closed to this recurring modification while new variants arrive through an explicit extension point. It does not say existing code must never change. It says repeated variation should stop causing shotgun surgery.

Single Responsibility Is About Change, Not Class Size

Mon, 01 Feb 2021 00:00:00 +0000

A class with one public method can still mix pricing policy, PDF layout, storage, and email delivery:

final class SendInvoice
{
 public function handle(Order $order): void
 {
 $tax = $order->subtotal * config('billing.tax_rate');
 $pdf = Pdf::html(view('invoice', compact('order', 'tax'))->render());
 Storage::disk('invoices')->put("{$order->id}.pdf", $pdf);
 Mail::to($order->customer)->send(new InvoiceMail($pdf));
 }
}

Its method count is one. Its reasons to change include tax rules, document presentation, retention, storage infrastructure, and delivery policy. “Do one thing” is too vague to expose that coupling.

The Single Responsibility Principle is more useful as a change rule: group code that changes for the same reason and separate code that changes for different reasons. Robert Martin’s clarification of SRP connects those reasons to the people or business functions requesting them.