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 constructor is cleaner, but the direction is still wrong. The application use case knows an HTTP client, carrier endpoint, payload, response shape, and currency assumption. Moving new Client() into the container made assembly easier. It did nothing to keep carrier details out of application policy.

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. It is the provider’s feature catalogue pretending to be a client role.

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 type checker did its job; it just was not the whole job.

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, and method count is a lazy proxy for it.